Receiving and Logging Requests; Publishing Your Rules

Readiness note. This is a private training programme. It builds knowledge and readiness. It does not grant any official certificate, licence, or government recognition, and it does not create any affiliation with a regulator or an agency. On passing, learners receive a Record of Completion. This unit is general education. It is not legal advice.

Mission briefing

A message arrives. It says it is from the police, and it asks for a user's data. Who in your company reads it? Where is it written down? Who decides?

If you cannot answer, the request is handled by whoever opens it first. That is how user data reaches the wrong person, and how a lawful request is lost.

Focus: one door, one request log, a small team that keeps requests to itself, and one published page that tells requesters how to ask.

Learning objectives

By the end of this unit, you will be able to:

• Say what a request for user data is, and who may lawfully make one.
• Set up one channel for requests, with an acknowledgement and a reference number.
• Keep a request log with the right columns.
• Say who may see a request, and what staff may say about it.
• Fill in a "What do we hold?" worksheet for your own service.
• Check your rules for authorities against thirteen points.

Why this matters to you

• Companies and compliance teams: you hold other people's data. A request tests two duties at once: your duty to obey lawful process, and your duty to protect your users. Good intake is where both start.

1. What is a request, and who may ask?

A request for user data asks your company to do something with a user's records for a public authority. There are three main kinds.

• Preservation. Keep a copy safe. Give nothing yet (unit P4, Preservation and Emergency Requests).
• Disclosure. Hand over named records. This needs a legal basis (unit P2, Verifying the Requester and the Legal Process; unit P3, Jurisdiction, Foreign Requests and Legal Sufficiency; and unit P5, Data Minimisation, Production and User Notice).
• Emergency disclosure. Hand over a small amount of data, at once, because a life is at risk (unit P4, Preservation and Emergency Requests).

A fourth kind looks similar and is not the same. A removal request asks you to take content down. It follows a different law and goes to a different team. Removal gives no evidence to anyone, and it can destroy records that someone needs (unit P6, Escalation, Challenge and Refusal).

Who may ask? Only a body with a legal power to ask: a police force, a prosecutor, a court, a regulator. A private person or a lawyer in a civil dispute is not such a body. Their requests follow other rules.

Two words matter from the first minute.

• A request asks. You may say yes or no, within your law.
• An order commands. A court or an authorised officer issues it under a named law. You must obey it, or challenge it by a lawful route.

Many messages do not say which they are. Finding out is part of the job (unit P2, Verifying the Requester and the Legal Process).

2. One door

Requests reach a company by many roads: the support inbox, a sales manager, a director's personal phone. Each road is a risk.

Set one channel for requests from authorities: a portal, a web form or one mailbox. Then set four rules.

1. Everything goes to the channel. Staff who receive a request elsewhere do not answer it. They pass it on the same day and tell the sender where to send it.
2. A separate line for emergencies. If your page promises an answer at all hours, staff it at all hours.
3. Acknowledge. Reply with a reference number and the date received. An acknowledgement confirms receipt. It promises nothing more.
4. Nothing leaves by another road. No member of staff sends user data from a personal account or by a chat message.

3. The response team: role and limits

Many providers have a small team for these requests. Be clear about what it is.

Its role: receive requests, verify them, check the legal basis, find the data, produce the minimum, keep the record, and say no when no is the right answer.

Its limits:

• It is not part of any investigation. It does not search for extra facts to help a requester.
• It does no favours for a useful contact.
• It does not decide hard cases alone. A second person reviews refusals, emergencies and anything unusual.
• It takes legal advice when the law is unclear.

Write down who may approve what (unit P4, Preservation and Emergency Requests).

4. The request log

The request log is one list of every request, kept from the first day. It protects users and the company, and it feeds your transparency report (unit P7, Transparency Reporting). Use one row for each request. These columns work for most companies. Each line below names a column, then says what to write in it.

The request log holds no more personal data than it needs, and few people can read it.

5. Who sees a request

A request is itself sensitive. It says that a named person interests the police.

Staff tell nobody outside the team that a request exists or what it asks.

Three working rules support that line.

• Need to know. Only the response team sees requests and the request log.
• No private use. Staff never look up an account for their own reasons, and every search for a request is logged.
• Declare a conflict. A member of staff who knows the user steps aside.

Many countries back this with their own secrecy law. The India and Australia editions each have a unit with those rules (unit P9, India: Intermediary, Telecom and Data-Protection Duties; and unit P10, Australia: Carrier and Provider Duties). Whether and when you tell the user is a separate question (unit P5, Data Minimisation, Production and User Notice).

6. "What do we hold?"

You cannot answer a request well if you do not know your own data. Fill in a worksheet before the first request arrives. Answer six questions for each category of data.

1. What exactly is it?
2. Which system holds it?
3. How long do we keep it, and what deletes it?
4. Which identifier finds it: an account number, an email address, a phone number?
5. Who in the company can retrieve it, and in what format?
6. What can we not produce? Examples are content that is encrypted from end to end, and data the user has deleted.

The categories differ by sector. This panel gives a starting list for four kinds of company. Each row names the sector, then its typical records, then the points to watch.

Keep the worksheet current. It feeds point 4 of your rules for authorities.

7. When the data belongs to your business customer

Some companies hold data for other companies. A cloud host stores a hospital's files. The hospital decides why the data exists. The host only stores it.

The usual first answer is then: ask the customer. The customer controls the data. Many business-software providers publish this as their rule.

One region's law takes the same line, as an example. The European Union regulation on electronic evidence, which has applied since 18 August 2026, says an order goes to the company that acts as controller of the data. It may go to the company that only processes the data in two cases: where the controller cannot be found despite reasonable efforts, or where asking the controller might harm the investigation.

Write your rule down. Say when you send a requester to the customer, and what you will tell the customer about a request where the law lets you.

8. Publish your rules for authorities

A requester who knows your rules sends a better request. Publish them on one page, on your own domain. Unit X1 (Finding and Reading a Provider's Current Rules) teaches officers to read that page for ten questions. Check your page against these thirteen points.

1. Who we are. Which company serves which users, and which company accepts legal process.
2. How to reach us. One channel for requests and one for emergencies. What we ignore, such as messages to the support desk.
3. What a request must contain. The identifiers we can search, the fields we need, the file format and the language.
4. What we hold, and for how long. And what we cannot produce.
5. What legal process we need for each kind of data, from authorities at home and abroad.
6. Preservation. How to ask, how long we hold, how to extend.
7. Emergencies. The test in plain words. We decide case by case. We check the sender.
8. User notice. Our default, and what must be sent to delay it.
9. The reply. Format, time zone, any statement for court, any charge.
10. Removal requests are separate. A different channel and team.
11. Local duties. Any contact that a local law requires, and what it is for.
12. Transparency. A report at fixed intervals.
13. A date on the page, and a note of what changed.

State also what you never give without legal process. For most providers that is the content of private messages.

Good practice, from a real page. Reddit's guidelines for law enforcement, as published on 8 October 2026, showed a revision date at the top: 22 May 2026. The page named one company for users in the European Economic Area and another for all other users. It named one portal for all requests. It stated a preservation period, an emergency test, a user-notice policy and a separate section for content removal. It also said that the guidelines may change at any time.

Poor practice, seen on real pages (not named here):

• no date, or a page last updated two years ago;
• no legal entity named;
• rules that only a registered user of a portal can read;
• a privacy policy, terms of service and guideline that name different companies or channels;
• a transparency report that is years old.

Read your three documents side by side: privacy policy, terms of service, guideline. They must agree.

9. Keep it current

Give the page an owner. Review it on a fixed cycle, and whenever your service or the law changes. Date every internal note on a law or a procedure.

Worked example — a first request at "Tallow Pay" (invented)

Tallow Pay is a small payments app. On a Monday its support desk receives an email: "Police. Send all records for this phone number today."

Tallow Pay has one channel. The support agent does not reply with data. She forwards the email to the response team and tells the sender where the request form is.

Farid Okonkwo, on the response team, opens a request log row with a reference, the time and the channel. He acknowledges receipt. The email cites no law and comes from a free email address. He records that too. Verification is the next step (unit P2, Verifying the Requester and the Legal Process).

Nothing has been disclosed. Everything has been written down.

Activity — audit your own page

Open your company's rules for authorities. If none exist, use the page of any service you use.

1. Score the page against the thirteen points: yes, partly, or no.
2. Find the date. Is it less than a year old?
3. Read the privacy policy and the terms. Do they name the same company and channel as the guideline?
4. Pick one category of data. Can you answer the six worksheet questions for it?

Conclusion

You can now:

• tell preservation, disclosure, emergency and removal requests apart;
• run one door with an acknowledgement and a reference;
• keep a request log that shows what was asked, checked, decided and sent;
• limit who sees a request, and keep staff silent about it;
• map what your service holds;
• test your rules for authorities against thirteen points.

Where this unit sits. It is the first unit of this course and the mirror of unit X1, Finding and Reading a Provider's Current Rules. Next is unit P2, Verifying the Requester and the Legal Process. Unit P4 covers preservation and emergencies, unit P5 (Data Minimisation, Production and User Notice) covers production and user notice, and unit P7 (Transparency Reporting) covers transparency reports.

Complete the Learning Check for this unit.