How to handle police requests for customer data

A request from the police for a customer's data can land in any company's inbox. Handing that data over is regulated by the GDPR, so the company has to get two things right at once: meeting any obligation it has, and protecting the data it holds.

Before anything arrives

The most common problem is not a hard legal question. It’s that a request lands somewhere with no clear owner and sits there.

Decide in advance where requests should be sent, who handles them, and who takes over when that person is away. Requests are often time-sensitive, and days lost at the start are hard to make up.

Step 1: Check the request is genuine

Police requests almost always come by email, and email is easy to fake. An address can be forged, a signature copied, and an official-looking document attached.

Confirm the request really is from the authority before acting on it. The reliable way is to contact them through a number or channel you find yourself, not one printed in the email. Disclosing customer data to someone impersonating the police is a serious breach in its own right.

Step 2: Work out whether you have to comply

Some companies are legally required to hand over data when an authority asks. This typically covers banks and other financial firms, phone and internet access providers, and companies covered by anti-money-laundering rules, which have to answer to their national financial-crime unit.

From August 2026, the e-Evidence Regulation adds to this. It lets an authority in one EU country order online and communication service providers, such as telecom, hosting, marketplaces and social networks, in another country to hand over data directly. It covers certain cross-border cases only, and applies to those providers rather than financial firms.

For most other companies there is no standing duty. A request, even from a prosecutor, is a request. To compel disclosure, authorities normally need a decision from a court, or they seize the data, and in some countries a prosecutor can order it directly. Until something binding is in place, you are allowed to help, but not required to.

In practice most companies do help, and that is usually fine. The point is not to refuse, but to know which situation you are in, because it changes what you need before you disclose.

Step 3: Check what is being asked for, and what you may disclose

Requests are often broader or vaguer than they need to be. Work out exactly what is covered: which customer, which period, and which types of information. If that is unclear, ask the authority to specify.

Then make sure you are allowed to disclose it. If the law requires you to, that requirement is your basis. If nothing requires it, you cannot assume disclosure is allowed. You need a real reason for helping, weighed against the customer's privacy, and you have to be able to defend that decision later. Some regulators view voluntary disclosure to the police with caution, so it is not automatic.

Whatever the situation, disclose only what the request covers, not the wider account. And take extra care where the data concerns offences a person is suspected of or has been convicted of, since that is more tightly protected under the GDPR and needs clearer legal cover.

Step 4: Decide whether you can tell the customer

Normally you are expected to be open with customers about how their data is used. That can be restricted, but only where the law allows it or the request comes with a confidentiality condition, not because you would rather not say anything.

So check the request for any restriction, and if there is none, work out whether you are in fact required to inform the customer.

Step 5: Send the data securely

The reply is often more sensitive than the request. Sending it as an ordinary email is a weak way to handle it. Use a secure channel, such as encrypted email or secure portals, and make sure it reaches only the authority that asked.

Step 6: Record what you did

If a regulator or a court asks about a disclosure, it may be years later, and the answer should not rest on memory or a search through an old mailbox.

Keep a record of each request: what was asked for, who asked, what you checked, what you disclosed, when, and on what basis. Being able to show that you acted properly is part of the obligation.

Two situations that need extra care

A request from outside the EU. A demand from an authority outside the EU does not, on its own, give you the right to hand data over. It normally has to come through a formal agreement between countries, and sending data outside the EU brings its own rules. The safe course is to decline a direct request and point the authority to the official channel between governments.

A request that goes too far. If a request is unusually broad, unclear about its basis, or asks for more than the case appears to need, you can ask questions before disclosing. Asking an authority to clarify or narrow a request is not obstruction.

What good handling looks like

None of these steps is difficult on its own. The difficulty is doing all of them the same way every time, under time pressure. A workable process usually has five things:

One route in. A single address or channel for authority requests, with a named owner and a stand-in, so nothing sits unclaimed.

A verification step that is not optional. Every request is confirmed with the authority before anything is disclosed, using contact details you find yourself.

A rule on scope. Someone checks what is actually being asked for, and disclosure is limited to that, with any unclear request sent back for clarification.

A secure way to send. Encrypted email at a minimum, or a secure portal, so sensitive data is not moving as ordinary attachments. Some companies handle the whole flow in a purpose-built portal such as Reqport, which keeps verification, delivery and the record in one place.

A record kept as you go. What was asked, what was checked, what was disclosed, when and on what basis, written down at the time rather than reconstructed later.

None of this requires a large team. It requires deciding once how requests are handled, and then handling them that way every time. That is what keeps a company on the right side of both duties: helping a legitimate investigation, and protecting the data it holds.

---

Reqport is a platform for handling law enforcement and authority data requests. Each request is verified, encrypted end to end, and recorded in full, so nothing slips and you can always show exactly what was done. See how Reqport works.

---

This article is for informational purposes only and does not constitute legal advice. Many of the obligations described are implemented through national law, which varies by member state. For how they apply to your specific situation, consult qualified legal counsel.

Reqport

Reqport is a platform for handling law enforcement and other authority data requests.

LinkedIn