Transparency reporting for law enforcement requests: what to publish and how

What is a transparency report?

The core of every transparency report is the same set of facts: how many requests for user data the company received, from which governments, under what legal process, and what happened to each one. Complied in full, complied in part, rejected.

Google published the first one in 2010. Adoption grew slowly until the Snowden disclosures in 2013, after which the number of companies publishing grew 367% within a year. Today, somewhere near ninety companies publish them, from Apple and Meta down to mid-size SaaS companies whose entire report is one page and a table. The thin ones count too. A one-page report that says we received 14 requests and complied with 9 does the whole job: it tells users, regulators, and journalists that the company knows what's moving through it.

Are transparency reports required by law?

In the US, no. Publishing is voluntary, and always has been. But the direction of travel is one way.

• Germany's NetzDG (2017) was the first mandate, requiring biannual reports from large social networks.
• The EU Digital Services Act made it general. Article 15 requires intermediary services to publish transparency reports at least annually, machine-readable, within two months of period end; very large platforms report twice a year. The reports must count orders received from member state authorities, broken out by type, issuing country, and median response time. A November 2024 implementing regulation standardized the format.
• The EU e-Evidence Regulation, applying from August 18, 2026, adds a new class of cross-border orders that will need counting from the day it takes effect.

So the honest answer for a company with EU users: transparency reporting started as public relations and is finishing as compliance. The companies that built the habit voluntarily now have a head start on a legal requirement.

What should a transparency report include?

Reports vary widely, which is the field's longest-standing criticism: numbers that can't be compared across companies or even across one company's years. The core taxonomy that makes a report useful:

• Requests received, counted by legal process type: subpoenas, court orders, search warrants, emergency requests, preservation requests. A warrant count and a subpoena count are different facts. The full process ladder.
• Accounts affected, since one request can name hundreds of users.
• Outcomes: complied in full, complied in part, rejected or withdrawn. Compliance rate is the number sophisticated readers look for first.
• Requesting country, for anyone operating across borders.
• Content versus non-content, because handing over message bodies and handing over subscriber records are different events.
• Notice: how many users were told, and how many requests carried gag orders that prevented it.

Define each category once, publish the definitions alongside the numbers, and never change a definition without saying so. A report whose categories shift year to year isn't transparency, it's noise with a publication date.

What can you legally disclose?

Almost everything, with one carve-out: US national security process.

Ordinary criminal legal process, subpoenas, warrants, court orders, can be reported in exact counts. National security letters and FISA orders cannot. Under the USA FREEDOM Act, companies may report those only in aggregate bands, in increments of 100, 250, 500, or 1,000 depending on the reporting format chosen, sometimes with a mandatory delay. That's why every major report has a table that reads 0-249 national security letters. It's not coyness. It's the maximum the law allows.

• Gag orders under 18 U.S.C. § 2705(b) restrict telling an individual user about a specific request. They don't prevent aggregate reporting, which is precisely what makes the aggregate report valuable: it's the disclosure no gag can reach.
• Warrant canaries, the published statement that a company has not received secret process, designed to disappear when it has. Their legal standing has never been tested in court. Treat them as a supplement to a report, not a substitute for one.

How do you actually produce one?

Here is the operational truth most guides skip: a transparency report can't be written, it has to be accumulated. The report is a byproduct of how requests were handled all year. You can't report what you didn't track.

Companies with a real request management process produce a report in an afternoon, because every request that arrived was verified, classified by process type, and resolved with a recorded outcome. The report is a query. Companies without one assign a paralegal to a year of inbox archaeology, reconstructing counts from email threads and hoping the shared mailbox wasn't cleaned out in March.

For a company publishing its first report with a small team, the minimum viable version:

1. Pick a period you can actually reconstruct. A single half-year beats a fictional five-year history.
2. Count requests by process type and outcome. Skip country breakdowns and account counts if the data isn't there yet; add them next period.
3. Publish the definitions next to the numbers.
4. State what you'll report next time, and hold to the cadence.

Then fix the pipeline so report two is a query, not a project. How request management works end to end.

How often should you publish?

Annual is the floor and the norm for a first report; the major platforms publish semiannually. The DSA requires annual publication for services in scope, biannual for the largest platforms. Pick the cadence you can sustain, because a report that appears once and never again reads worse than no report at all.

For calibration on volume: Coinbase reported 12,716 law enforcement requests in its most recent reporting year, up 19%, with 53% from outside the US. Verizon reported 61,919 subpoenas in a single half-year. Your numbers will be smaller. Publish them anyway; the point of the report is the accounting, not the size.

Transparency reporting from Kodex

On Kodex, the report is the byproduct it should be. Every request arrives verified, classified by legal process type, jurisdiction, and outcome, so transparency-report metrics fall out of data the team already has. No reconstruction, no archaeology, no March mailbox problem. See how request management works.

Common questions