Skip to main content

Requests about previous information requests (meta requests)

About this detailed guidance

This guidance explains how you should deal with requests about previous information requests (meta requests), made under the Freedom Information Act 2000 (FOIA) or the Environmental Information Regulations 2004 (EIR). Read it if you have questions not answered in the Guide to FOIA or Guide to the EIR, or if you need further guidance on how to handle meta requests.

In detail

What is meant by a meta request?

A meta request is a request for recorded information about the handling of a previous information request, for example:

‘I would like copies of any information you hold concerning your handling of my recent Freedom of Information request.’

‘Please provide me with copies of all internal correspondence about the processing of my Freedom of Information request of 11 February 2014.’

‘Can you please send me copies of the documents showing how you dealt with my Environmental Information request.’

Meta requests do not have any special status under FOIA or the EIR, nor are there any specific exemptions or exceptions for this type of request. This means you should treat meta requests in the same way as any other information request.

This was confirmed by the High Court in Home Office and Ministry of Justice v Information Commissioner’s Office ([2009] EWHC 1611 (Admin), 6 July 2009) when it stated:

‘It is important to emphasise that information about how previous requests were handled is not accorded any special treatment in the [FOIA] Act. There is no provision in the Act which specifically permits requests about such information to be refused…The Information Tribunal (‘the Tribunal’) recognised that when it said in its decision in this case that

"Parliament intended that meta-requests should be dealt with in the same way as any other requests otherwise Parliament would have provided for this, which in our view they have not done.”’ (Para 4)

What is the difference between meta requests and internal reviews?

When a requester makes a meta request, they are exercising their right of access to the recorded information you hold about the handling of the original request. This is distinct from a request for internal review, which is a complaint about how you dealt with the original request.

This means that the internal review process should not be viewed as the equivalent of, or a substitute for, a meta request.

You should not refuse to comply with a meta request because you have already carried out an internal review, or refuse to carry out an internal review because you have already complied with a meta request.

However, requesters may submit meta requests because they are dissatisfied with how you handled the original request.

There is nothing to prevent you asking a requester if they would prefer the request to be dealt with as a complaint, if you have reason to believe that:

  • the requester is unhappy with the response to the original request; and
  • their concerns could be better addressed through your complaints/internal review procedure.

However, if you intend to offer this option, you should do so promptly. This is because you will remain obliged to comply with the meta request unless the requester explicitly consents for it to be treated as an internal review.

If a requester replies that they want an internal review and a response to the meta request, then, again, you must process the meta request. You should also refer to part 5 of the section 45 Code of Practice (if the request is an FOI request), or to our guidance Internal reviews under the EIR (if the request is for environmental information) for further details on how to handle the request for an internal review.

What if a meta request is unclear?

You should go back to a requester and ask for further clarification if you are unsure what the requester is asking for, and in particular if:

  • you can’t locate or identify the requested information;
  • you are unclear whether the requester is making a meta request, complaining about the response to the original request, or both; or
  • the requester has made several previous requests for information and you are not clear which of these the meta request relates to.

What about exemptions and ‘neither confirm nor deny’ responses?

If you withheld information when you responded to the original request under an exemption or exception, then the material caught by the meta request may also contain some of that previously withheld information.

However, there is no special provision in FOIA or the EIR to withhold information in response to a meta request on the grounds it was exempt from disclosure at the time of the original request.

Therefore, if you still believe the information is exempt, you must apply the appropriate exemption or exception within FOIA or the EIR. In most cases this is likely to mean re-applying the exemption used to withhold the information in response to the original request.

Example

A government department receives a request for a report into the safety of a new vaccine.

The report had concluded that the vaccine could have severe side effects in rare cases. The department is concerned that releasing this information could deter people from getting vaccinated, risking their health and increasing the likelihood of the disease spreading. It therefore withholds the report under section 38 of the FOIA on the grounds that disclosure would be likely to prejudice the health and safety of members of the public.

Following this, the requester submits a meta request for all correspondence about the processing of their original request.

The information caught by the meta request includes an email by the report’s author which advises the department not to allow information about the severe side effects to be made public.

The disclosure of this email would entail the release of information that was withheld in response to the original request under section 38, namely the fact that the vaccine could have severe side effects in rare cases.

However, there is no special provision in FOIA to withhold information on the grounds it was exempted in response to a previous request. Therefore, if the department is satisfied that disclosing details of the vaccine’s effects would still prejudice the health and safety of members of the public, then it will have to apply section 38 to the relevant information in the email.

If you claimed an exemption from the duty to confirm or deny at the time of the original request and then receive a meta request on how you handled the original request, you can consider whether a ‘neither confirm nor deny’ (NCND) response would be appropriate to the meta request.

There is no provision in FOIA or the EIR to withhold information in response to a meta request on the grounds that disclosure would undermine a previous NCND response.

Therefore, if you intend to issue an NCND response to a meta request, you must be clear how an NCND exemption is engaged regarding that request. The NCND exemption cited in response to the original request is not automatically engaged for the meta request.

What is the relationship between meta requests and section 36: Prejudice to the effective conduct of public affairs?

Section 36 of FOIA provides an exemption from the duty to disclose information where this would be prejudicial to the effective conduct of public affairs. It is a qualified exemption so it is subject to a public interest test. If you apply section 36 to a meta request, you should focus the public interest arguments in favour of maintaining the exemption on the consequences of disclosing the specific information caught by that request. In line with First-tier Tribunals, the ICO gives little weight to section 36 arguments that are not linked to the disclosure of the requested information.

The ICO’s view is that you should give little weight – as public interest factors in favour of maintaining the exemption – to general arguments that aren’t linked to the consequences of disclosing the specific information.

In FS50482167, the requester made a meta request to the Department for Communities and Local Government (DCLG) for letters and emails about his previous FOI request made on 25 July 2012.

The original request was for ‘…all communications relating to Hatfield town team’s successful bid for a Portas Pilot award’.

The DCLG provided some of the information within the scope of the meta request but refused the rest under section 36.

One of the DCLG’s arguments in favour of maintaining section 36 was the need for ‘safe space’ regarding its consideration of the original request. However, the DCLG failed to link this line of argument to the specific information being considered.

The Commissioner observed that:

’…as the safe space required would not be for the formulation of policy, but rather for exchange of views or advice on how to meet its statutory obligations under the FOIA, the inhibition claimed would not be particularly severe or widespread given that there are statutory parameters within which a request has to be dealt with. He does not consider that there is significant public interest in protecting a safe space in relation to statutory obligations designed to promote openness and transparency in government and DCLG has not provided reasons as to why such a safe space is needed in relation to the specific withheld information.’ (para 47)

What public interest factors in favour of disclosing the information caught by a meta request should we consider?

If you have applied an exception under the EIR or a qualified exemption under FOIA to a meta request, and are considering the public interest factors in favour of disclosure, you should give some weight to the inherent public interest in:

  • increasing the transparency and accountability of the request handling and decision making process;
  • helping the public better understand the reasoning behind decisions; and
  • fostering public confidence in the request handling process.

You may feel you already serve these interests by having an internal review process, or through publishing your request handling procedures online. However, the fact you have clear procedures in place does not guarantee that they are adhered to, or that your internal reviews are thoroughly conducted. This means meta requests have an inherent public interest value as an alternative means of scrutiny, independent of your own request and complaints procedures.

The Tribunal case Home Office and Ministry of Justice vs ICO (EA2008/0062, 20 November 2008) concerned a request by Matthew Davis for documents about his company’s use of FOIA.

Mr Davis submitted this request because he believed his company’s requests were ‘…deliberately handled differently to other members of the public, which is a clear abuse of the act on your part as you should be ‘applicant blind’ when dealing with requests’.

The Home Office provided some of the information and withheld the rest under section 36 (prejudice to the effective conduct of public affairs).

However, the matter was referred to the Commissioner, who ruled that the balance of the public interest lay in favour of disclosure.
The Tribunal found that the Commissioner had made the correct decision. When considering the balance of the public interest, it stated:
‘We have given strong weight to the public interest in knowing that public authorities deal with FOI requests properly and lawfully and do not discriminate against requesters or between requesters. This is the particular public interest raised by Mr Davis himself. It is vital to show and to be seen to show that the fundamental compliance processes of the Act are being observed.’ (para 65)

What is the relationship between meta requests and personal data?

The information caught by a meta request is likely to contain a mixture of the requester’s own personal data and third party personal data (principally the personal data of the employees who dealt with the original request). The requester’s own personal data is exempt from disclosure under section 40(1) of FOIA and should be handled under the right of access provisions of the UK General Data Protection Regulation and the Data Protection Act 2018.

For further information on how to handle this issue, please see our guidance on Personal data of both the requester and others and Requests for personal data about public authority employees.

What about vexatious or manifestly unreasonable meta requests?

Under section 14 of FOIA, you do not have to comply with requests that are vexatious. The equivalent provision in the EIR is regulation 12(4)(b), the exception for manifestly unreasonable requests.

We have dealt with several cases where public authorities have supported their decision to apply section 14 to a meta request with general arguments around the theme that such requests are, by nature, obsessive or lacking in any serious purpose of value. In the ICO’s view, there is nothing intrinsically vexatious about a request for information about a request. It follows that you should not treat meta requests as vexatious as a matter of course.

Rather, you should only consider refusing a meta request as vexatious if you can point to specific evidence that the request will cause a disproportionate or unjustified level of disruption, irritation or distress on its own merits.

Further advice on identifying and dealing with vexatious requests is available in our guidance Dealing with vexatious requests and Manifestly unreasonable requests – regulation 12(4)(b).

When can we refuse meta requests based on cost limits?

The ICO has also dealt with several cases where authorities have cited cost or burden as grounds for refusing a meta request.

The ICO does not consider there to be anything inherently costly or burdensome about a meta request. The ICO therefore expects to consider cost and burden on a case by case basis, as with any other type of request.

If you have concluded that the cost of compliance would be excessive, you should deal with the meta request under section 12 of FOIA (cost limits).
There is no direct equivalent to section 12 in the EIR. However, you can take the cost of compliance into account as part of a claim that a request is manifestly unreasonable.