Reasonably Necessary And Proportionate

Expanded Definition

Reasonably necessary and proportionate is a privacy and data minimisation test used in CPRA analysis to determine whether collection, retention, or use of personal information is justified by a stated business purpose. It is not a generic “best effort” standard. The question is whether the data element supports the purpose in a direct and defensible way, and whether a less intrusive design could achieve the same result. In practice, this requires teams to document the purpose first, then justify each data field against that purpose.

That makes the standard broader than simple collection notices and narrower than open-ended consent language. It also differs from internal convenience arguments, because operational usefulness alone does not make collection proportionate. Where security, fraud prevention, or account protection is involved, the analysis often overlaps with control design and data governance, including ideas reflected in the NIST Cybersecurity Framework 2.0. The industry still varies in how rigorously it documents this test, but the direction is consistent: purpose limitation should drive collection design, not the other way around. The most common misapplication is treating broad internal preferences as a valid purpose, which occurs when teams collect extra data “just in case” without a specific and documented need.

Examples and Use Cases

Implementing reasonably necessary and proportionate rigorously often introduces friction between product convenience and privacy assurance, requiring organisations to weigh faster onboarding against narrower data collection and stronger justification.

• A fintech app collects date of birth to meet age verification needs, but does not add unrelated demographic fields unless they support a documented decision or regulatory obligation.
• A customer support workflow limits identity verification to the minimum data needed to resolve the ticket, rather than pulling full profile history for every request.
• A security team designing fraud checks documents why device signals, geolocation, or step-up verification are proportionate to the risk being addressed, instead of collecting all available telemetry by default.
• An employer reviewing applicant data avoids requesting sensitive personal information that is not necessary for hiring eligibility or legally required screening.
• A cloud service keeps only the account attributes needed for access control and billing, rather than replicating extra personal information into secondary systems without a purpose review.

For privacy-by-design decisions, the standard is often operationalised alongside California privacy guidance and broader minimisation principles. Where identity proofing is involved, teams should also consider whether stronger verification can be achieved with fewer attributes, rather than expanding collection scope. The use case is especially important when a business asks for “optional” data that later becomes functionally required, because that undermines the proportionate design assumption.

Why It Matters for Security Teams

Security teams often become involved when privacy requirements collide with logging, monitoring, fraud detection, or identity verification. Reasonably necessary and proportionate matters because poor data minimisation increases exposure: more records to protect, more systems to govern, and more risk if a breach, misuse, or retention failure occurs. It also sharpens accountability. If a team cannot explain why a field is needed, it is unlikely to defend why it should be collected, retained, or shared.

That is where governance frameworks become useful. NIST guidance on risk-based control selection, including the NIST Cybersecurity Framework 2.0, supports the idea that controls should align with purpose and risk, not habit. In privacy operations, the same logic helps teams resist scope creep in telemetry, IAM records, and third-party data exchanges. For NHI and agentic AI environments, the principle is increasingly relevant when systems request broad user or context data for automation that does not clearly require it. Organisations typically encounter the consequences only after a complaint, regulator inquiry, or incident review, at which point reasonably necessary and proportionate becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Why is it necessary to address authorization challenges in AI agent deployment?
• When does NHI automation become necessary?
• When do AI agent guardrails become necessary instead of optional
• When does just-in-time access become necessary for NHI governance?