Manifestly Unfounded Or Excessive Request

How the threshold works

This term exists to prevent privacy rights from being turned into a channel for abuse. The key question is not whether a request is inconvenient, but whether its pattern, purpose, or repetition shows that it is not being made to genuinely exercise a right, or is being used in a way that creates an unreasonable burden for the organisation.

That distinction matters because privacy regimes generally expect organisations to respond in good faith, but they also recognise that access rights are not absolute in the face of abusive or excessive conduct. The threshold is deliberately high, so refusal or charging a fee is reserved for cases where the facts support that conclusion.

Why organisations treat it differently

A manifestly unfounded request usually signals bad faith, while an excessive request often signals volume, repetition, or scope that is disproportionate to the purpose of the right being exercised. Either way, the issue is operational as much as legal: staff time, search effort, identity verification, redaction, and review work can become disproportionate if the same requester keeps returning with overlapping demands.

In practice, the organisation is assessing burden, pattern, and context together. A request can be valid in principle but still cross the line if it is repetitive, harassing, or clearly designed to disrupt normal privacy operations rather than to obtain a lawful outcome.

How teams should assess the request

The assessment should focus on evidence, not frustration. Teams usually look at the requester’s history, the similarity of prior requests, whether the scope has changed, whether the request is tied to a real rights exercise, and whether the organisation can still respond proportionately without duplicating work already completed.

It is also important to separate a difficult request from a manifestly unfounded one. A broad, awkward, or resource-heavy request is not automatically abusive. The label should only be used when the organisation can point to a clear basis for concluding that the request is unfounded, excessive, or both.

Where a privacy programme is designed around DSAR handling at scale, the same intake discipline that helps with deadlines and exemptions also helps teams recognise when repetition, volume, or poor-faith behaviour is driving the burden.

What happens after refusal or a fee decision

If the threshold is met, the organisation may refuse the request or charge a reasonable administrative fee, but only within the limits allowed by the applicable privacy law. The decision should be defensible, proportionate, and consistent with the organisation’s documented process, because the requester may challenge it if the reasoning is thin or the evidence is weak.

Good handling also means preserving an audit trail. Even where the request is refused, the organisation should still be able to show how it assessed the facts, what part of the request caused the burden, and why the chosen response was the least disruptive lawful option.

Risk and Threat Considerations

Abusive or repetitive privacy requests can be used to consume operational capacity, delay legitimate handling, or pressure staff into making errors in search, disclosure, or redaction. The risk is not only volume, but also misuse of a lawful process to create distraction, cost, or inconsistency.

Failure mechanism: The organisation treats repeated or bad-faith requests as ordinary demand, then absorbs avoidable effort until response quality, timing, or oversight deteriorates.

Impact: Legitimate request handling can slow down, privacy teams can be overloaded, and the organisation may increase the chance of missed deadlines, incomplete responses, or unnecessary disclosure.

Practitioner Guidance

Governance implication: Set a clear internal decision path for threshold calls, because this is a judgement exercise that needs consistency across legal, privacy, and operational teams. The decision should be recorded with the facts that support unfoundedness or excess, not with vague character assessments of the requester.

What to watch for: Repeated near-identical requests, abrupt escalation after a complete response, and requests that appear designed to generate workload rather than obtain information. Those patterns are often more useful than the requester’s tone when deciding whether the threshold has truly been met.

Related resources from NHI Mgmt Group

• How should teams design metrics collection for very high request volumes without creating lock contention or excessive overhead?
• What is the difference between network trust and request-level identity trust?
• Why do access-request workflows matter for NHI governance?
• How should organisations use AI in access request approval without weakening control?