Manifestly unfounded or excessive GDPR requests: when to refuse or charge

When can you refuse or charge for a manifestly unfounded or excessive GDPR request?

Article 12(5) lets a controller either charge a reasonable fee or refuse to act when a data subject request is manifestly unfounded or excessive, but the default is that information and actions are free of charge, and the controller bears the burden of demonstrating that the request has that character. If a request channel is producing repeat or abusive requests and the budget owner wants to know whether refusing or charging is allowed, the answer depends on the pattern of requests, the controller's own records of them, and whether each decision was documented at the time. The GDPR sets no fixed fee, no request count and no threshold that makes a request excessive. Those judgments belong to the controller, and a regulator will test them against the facts in the file.

The practical starting point is a request log that shows who asked, what they asked for, when, through which channel, and what the controller did. Without that record, a claim that requests are repetitive cannot be shown. The EDPB's small business guide illustrates the point with a carpenter that receives an access request every two months from a one-time customer. That example is illustrative, but it shows the three options in play: treat the repeats as excessive, charge a fee based on administrative cost after informing the person, or refuse with reasons and information on the right to complain to an authority. Each option still requires a reasoned, recorded decision. Confirm your own position with your data protection lead or counsel before adopting a standing policy.

DeployOpen can help prepare the systems that make these decisions defensible, such as request logging, ticket fields for the reason and date of each decision, and reporting on repeat requesters. The controller still owns the call on each request and the wording of any refusal or fee notice. Ask any implementation partner to show, in writing, which records the controller will hold and who approves refusals. Before you refuse anything, check the EDPB guidance on the right of access and confirm which request pattern your organization is willing to defend to a supervisory authority.

Fee, refusal or full response: which option fits the request pattern

An unfounded request is one where the requester has no genuine intention of exercising the right, or where the request is plainly abusive, for example when data is sought to harass staff or disrupt operations. Article 12(5) allows the controller to refuse or charge a reasonable fee, but the controller must be able to demonstrate that the request is unfounded. Refusal is a last resort that needs evidence, so the first step is to confirm the requester's identity and establish exactly what was asked.

Test the purpose: An angry or demanding tone is not enough on its own. Look for evidence that the request is a tactic, such as a stated plan to use the data to damage the controller.
Record the evidence: Keep the messages, the context and the reasoning in the request file, dated to the day the decision was made.
Give reasons and remedies: Within one month, explain why the request is refused and state the right to complain to a supervisory authority and to seek a judicial remedy (Article 12(4)).
Answer the genuine parts: Where part of a request is valid, respond to that part in full and limit any refusal to the element that is unfounded.

Before relying on a refusal, confirm that your team could show the evidence to a regulator, because the burden of proof sits with the controller.

How to calculate a reasonable fee and give reasons within one month

This sequence lets the controller decide, with evidence, whether a request may be charged for or refused, and ensures the requester receives a fee notice or written reasons, with complaint and judicial remedy information, within the one-month period that Article 12 sets.

Record the facts that make the request excessive
The person who handles the request logs the requester's identifier, the date of receipt, the full history of earlier requests from the same person, and any stated purpose or pattern, such as repeated identical requests within a short period. The controller bears the burden of demonstrating that a request is manifestly unfounded or excessive, so this record must exist before any decision is taken. The step is complete when the request file holds a dated, factual account that a supervisory authority could read without further explanation.
Test the request against the manifestly unfounded or excessive standard
The data protection lead or DPO, where one is designated, compares the recorded facts with the test in Article 12(5), asking whether the request is clearly without foundation or, in particular because of its repetitive character, excessive. A single request from a new data subject will rarely meet this test, while a request repeated at short intervals after a full answer may. Mere inconvenience, a broad request or a request made during a dispute is not enough on its own, so the reviewer should write down why each fact supports or does not support the conclusion. The output is a documented decision to proceed normally, charge a fee, or refuse.
Confirm the requester's identity before deciding
Before the controller relies on repetition to charge or refuse, the team confirms that the earlier requests and the current one really come from the same person, using the identity checks the controller already applies to rights requests. If identity cannot be established, the controller must not assume a pattern of abuse from requests that may have come from different people. The step ends with a note in the file stating whether the identity link is confirmed, and the decision is held until it is.
Calculate the fee from the cost of responding
If the controller chooses to charge, the finance or operations owner calculates a reasonable fee based on the administrative cost of answering the request, such as staff time for searching, retrieving, reviewing and redacting data, and any system or processor charges that the response triggers. Article 12(5) requires a reasonable fee, not a penalty, so the calculation should use recorded hours and rates rather than an estimate with no basis. The controller should ask its own finance team and any processor for those cost inputs in writing. The output is a costed worksheet that can be shown to the requester and kept as evidence.
Inform the requester of the fee before charging it
The controller sends the requester a written notice that states the proposed fee, the basis of the calculation, and the option to proceed or to change the request, and it does not start processing that depends on payment until the notice has been sent. The EDPB small business guide describes informing the person before charging as the expected step. The notice must not route payment through a channel that makes exercising the right harder, which is the failure behind the Spanish enforcement case. The step is complete when the notice and its delivery date are on file.
Decide to refuse, with reasons, where the fee route does not apply
Where the controller concludes that the request is manifestly unfounded or excessive and chooses not to charge, it prepares a refusal that explains the specific reasons, drawn from the documented facts, without generic wording. The DPO or legal reviewer checks that the reasons match the file and that the refusal does not rely on the requester's identity being doubtful unless that was established. The output is a signed-off refusal letter and a copy of the decision record.
Send the reasons and remedy information within one month
Whatever the outcome of the earlier steps, the controller must deliver its response within one month of receipt, or extend it under Article 12(3) and tell the requester within the first month. Where the controller does not act on a request, Article 12(4) requires it to explain why within one month and to inform the requester of the right to complain to a supervisory authority and to seek a judicial remedy. Article 12(3) and 12(4) set these duties, and no fee figure is supplied here, so the controller must set and document its own cost basis. The step is complete when the dispatch record shows the date sent, the reasons, and both remedy statements, and the request file is closed with that evidence attached.

What the refusal notice must contain

Refusing or charging a fee for a rights request is only defensible if the notice to the requester is complete. Each element below is something the controller must be able to show, both to the requester and to a supervisory authority that later reviews the decision.

Reasons for not acting

The notice must explain specifically why the controller is not acting on the request, citing the facts that make it manifestly unfounded or excessive, such as the request count, timing and pattern. A generic statement that the request is excessive does not meet the requirement. Check that the reasons match the actual request log entries and that they are stated within one month of receipt.

Right to complain

The requester must be told they can lodge a complaint with a supervisory authority. Name the authority that is competent for the controller's establishment or the requester's place of residence, and give a working route to file. Check that the wording is included in every refusal template, including those sent by support staff who handle requests outside the main process.

Right to judicial remedy

The notice must also state that the requester can seek a judicial remedy. This is separate from the complaint route and must appear in the same notice. Confirm with counsel which courts apply in the relevant Member State and check that the template does not imply that the complaint route is the only option.

Internal decision record

Keep a dated internal record of the decision, the evidence that the request was manifestly unfounded or excessive, and who approved the refusal or fee. The controller bears the burden of demonstrating that character, so this file is what it will produce if the decision is challenged. Store it alongside the request log so the reasons can be reproduced later.

Communication channel used

Send the notice through the same channel the requester used, or the channel they asked for, and keep proof of delivery. A refusal sent only to an address that the requester cannot easily reach, or one that requires payment to read, can itself be a problem. Check that the channel does not require a fee or an identity step that the requester has not already been asked to complete.

What the Securitas Direct decision shows about obstructive request channels

The Spanish supervisory authority's decision against Securitas Direct shows that a controller cannot make it costly or hard to exercise data subject rights and then treat the resulting requests as excessive. The authority fined the company EUR 100,000 under Article 12(2) because people were directed to a chargeable telephone number to exercise their rights. The final decision is dated 1 February 2023, and the EDPB published its news item on 22 September 2026. The authority also ordered the company to replace the notices within 12 months, so the defect was in the channel itself, not in any individual refusal.

The lesson for request handling is that the channel is part of the controller's compliance position. If the only route to a request is a paid line, a form that does not work, or a process that asks for more than the request needs, the controller has created the obstruction it later cannot justify under Article 12(5). Before relying on the manifestly unfounded or excessive exception, confirm that every published route (email address, web form, postal address and telephone line) is free, works, and is described consistently in privacy notices and website text. Check that staff who receive requests on any channel know how to route them without charging or redirecting the requester.

For a product or platform team, this is a configuration and content check, not only a legal review. Ask who owns each intake channel, when each was last tested end to end, and whether a request sent to a non-standard address still starts the one-month clock under Article 12(3). Record the test results as evidence. If a channel must cost money or go through a third party, the controller should be able to show that the cost is not borne by the requester and that the route does not depend on that cost to be used.

Where refusals go wrong and how to avoid it

Most failed refusals and fees are not decided on the merits. They fail on process: missing records, skipped notices, late replies or a channel that makes the right to access harder to use. Each card below names one error, why it matters for a manifestly unfounded or excessive request, and what to check before you answer.

Refusing on volume alone

A high number of requests is not, by itself, proof that a request is manifestly unfounded or excessive. Article 12(5) puts the burden on the controller to demonstrate that character. Before refusing, record the requester's history, the number and timing of requests, whether they repeat the same demand without new reason, and what each response cost to produce. Without that file, a refusal reads as an assertion. Ask your DPO or counsel to review the record before you send anything.

Charging a fee without prior notice

The EDPB's small business example expects a controller that charges a fee to inform the person first. Charging silently, or billing for a request that was never shown to be excessive, is an error in its own right. Before any charge, state the basis, give the requester a chance to withdraw or narrow the request, and calculate the fee from your actual administrative cost. Keep the calculation on file so you can show how the figure was reached.

Missing the one-month deadline

The default deadline is one month from receipt. An extension of two further months is available only for complex or numerous requests, and only if the requester is told of the extension and its reasons within the first month. Refusals are also covered: if you do not act, you must explain why within that same month. Log the receipt date in your request tool, set reminders at the start of week three, and do not rely on a fee request to pause the clock unless your counsel confirms it does.

Sending a refusal without complaint information

A refusal that gives reasons but omits the right to complain is incomplete. Article 12(4) requires the controller to tell the requester that they may lodge a complaint with a supervisory authority and seek a judicial remedy. Build this paragraph into your refusal template, name the authority that is competent for your establishment, and check the wording with counsel. A template that leaves the paragraph blank is one of the most common defects auditors and regulators find.

Using a paid or hard-to-reach channel

The Spanish DPA fined Securitas Direct EUR 100,000 under Article 12(2) for directing people to a chargeable telephone number to exercise their rights, and ordered the notices replaced within 12 months. The same risk applies to request forms that need a paid postal stamp, a premium line or a mailbox nobody monitors. Offer at least one free, electronic channel that is published in your privacy notice, test it monthly, and confirm that messages reach the team that handles requests.

Ignoring the requester's chosen format

Article 15(3) expects electronic requests to be answered in a commonly used electronic form unless the requester asks otherwise. Refusing or delaying a request because the requester's channel or format is inconvenient for your team creates a second breach on top of the first. Configure your request workflow to produce standard electronic output, and confirm with your engineering team that exports can be generated from the systems in scope without manual rework.

Who decides, who prepares the records and who checks the decision

The controller is responsible for every decision to charge a fee or refuse a request under Article 12(5). In most organizations the data protection lead or the designated DPO owns that judgment, since the decision touches lawful handling of personal data and the rights of the individual. The decision owner should set the criteria in advance, such as how often the same person may ask, whether requests are repetitive in substance, and what the administrative cost of a copy is. Each refusal or fee needs a documented rationale that can be shown to a supervisory authority later.

Written criteria: Set out what counts as repetitive or excessive before the first contested request arrives.
Authority to refuse: Name who may sign a refusal and who must be consulted before a fee is charged.
Reasons and remedies: Confirm the template includes the explanation, the right to complain to a supervisory authority and the option of a judicial remedy.
Consistency: Record how comparable requests were handled so decisions can be compared.
Review trigger: Define when a repeat requester is re-assessed, rather than leaving the file open.

Check that the decision owner can name the criteria, the signatory and the review trigger without consulting anyone else.

Frequently asked questions about refusing or charging for GDPR requests

Can we refuse a data subject request because the same person keeps asking?

Yes, but only when the repetition makes the request manifestly unfounded or excessive, and you must be able to prove it. Article 12(5) places the burden of demonstrating that character on the controller. The EDPB small business guide gives an illustrative case: a carpenter receiving an access request every two months from a one-time customer may treat the repeats as excessive. Before relying on that, check whether new data has been collected since the last response, because a fresh request covering new processing is not a repeat in the same sense. Record the earlier requests, the dates, and why the new one adds nothing, so the decision can be defended to a supervisory authority.

How do we calculate a reasonable fee for a manifestly excessive request?

The fee should reflect your administrative cost of handling the request, not a penalty or a fee for the data itself. The EDPB guide describes charging based on administrative cost after informing the person. The cost drivers are staff time for searching systems, reviewing records, redacting third-party data, and assembling the response, plus any tooling or processor assistance you pay for. Keep a simple log of hours and tasks per request so the figure can be justified. Remember that information and actions are otherwise free of charge under Article 12(5), so the fee is an exception, not a default. Ask any external adviser to show how their time is priced against the actual work.

Do we have to tell the person about a fee before we charge it?

Yes. The EDPB guide's example depends on informing the person before the fee is charged, so the requester can decide whether to proceed. Tell them the amount or the basis of calculation, explain why the request is treated as excessive, and state that the request will be handled once payment or confirmation is received. Keep the notice in writing and store it with the request file. If you cannot show that the requester was informed, the fee becomes difficult to defend, and a supervisory authority may treat the charge itself as non-compliant with Article 12.

Does the one-month deadline still apply if we refuse the request?

Yes. If you do not act on a request, Article 12(4) requires you to explain why within one month of receipt. That explanation must also tell the data subject that they can complain to a supervisory authority and seek a judicial remedy. A refusal therefore starts the clock on a response, it does not pause it. The one-month period under Article 12(3) can be extended by two further months for complex or numerous requests, but only if you tell the person of the extension and its reasons within the first month. Build the refusal template with these elements so no step is missed.

Can we refuse a request simply because it is large?

Size alone is not a reason to refuse. Article 12(3) addresses numerous or complex requests through a possible two-month extension, and the test for refusal under Article 12(5) is whether the request is manifestly unfounded or excessive. A broad access request covering many systems may be complex, which supports an extension, but it is not automatically excessive. Where volume is the problem, consider whether the scope can be narrowed through a conversation with the requester, documented as such. Your engineers can reduce the burden by maintaining an inventory of systems and processors, since that determines how long a search takes.

Do we need outside help to document these decisions?

Not necessarily, but the documentation must exist, and the controller owns it. The organization is responsible for deciding whether a request is excessive and for proving it. Outside help can prepare the request log, systems inventory, search records and templates, or review how refusals are worded. Only your own decision-makers can make the determination, and a qualified data protection adviser can check the reasoning. Ask any provider to confirm what they deliver, who keeps the records, and how the work fits your written scope before work starts. DeployOpen prepares systems and records for this process in a client's own infrastructure, but it does not make the legal determination.

What happened when a company made its request channel chargeable?

The Spanish DPA fined Securitas Direct EUR 100,000 under Article 12(2) for directing people to a chargeable telephone number to exercise their rights. The final decision is dated 1 February 2023, and the EDPB published the case on 22 September 2026. The authority also ordered the notices to be replaced within 12 months. The lesson for engineers is that every rights channel, including web forms, email and phone lines, must be free to use. Check your intake points, automated replies and customer service scripts, not only the policy page.

How DeployOpen works on this

DeployOpen helps teams prepare the systems, workflows and written records that decide whether a request can be refused or charged for. We plan and implement self-hosted open-source platforms inside your own infrastructure, so the evidence of why a request was unfounded or excessive stays under your control. Your organization keeps responsibility for every decision.

How we scope

We agree a written scope covering which request channels, intake forms and tracking systems are included before work starts.
The scope defines which request types, such as access, erasure and repeat requests, the team needs to classify and log.
Scope documents who owns each decision on fees, refusals and reasons, so your team and any counsel know their roles.

How we build

We configure request tracking to record receipt dates, the one-month clock and any extension notices required under Article 12.
We set up fields that capture the facts behind a manifestly unfounded or excessive finding, such as request frequency and prior responses.
We test that intake channels do not route people to chargeable or hard-to-reach contacts, and document the test results.

How we hand over

You receive written documentation of the workflow, configuration, roles and the templates used for refusal and fee notices.
We provide a record of each test, showing how the tracking system handles repeat requests and the reasons it records.
Handover includes a short walkthrough so your staff can run the process and explain it to an auditor or supervisory authority.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover changes to intake channels, tracking configuration and templates when your processing or legal guidance changes.
Whether your organization needs an independent review of its decisions is a question for a qualified advisor or the relevant authority to answer.

Manifestly unfounded or excessive GDPR requests