A Subpoena Is Not a Permission Slip

A Subpoena Is Not a Permission Slip

A copyright subpoena filed in New York this month asks two of the largest platforms in the world to hand over device identifiers, IP addresses and cloud storage contents for everyone who spoke in three chat servers since June. Set aside who is right about the underlying dispute. For anyone who holds user data the question is narrower, and worse: how much of that would your company have handed over?

Friday, 4:40 p.m.

A subpoena lands in the shared legal inbox of a mid-size software company. It is signed by a court clerk, it carries a real case caption, and it gives fourteen days. It asks for account records, registration and last-login IP addresses, phone numbers, device identifiers and linked third-party accounts for every user who posted in a particular workspace over a three-month window.

Nobody at the company has seen one of these before. The general counsel is a contractor who works Tuesdays and Thursdays. The engineer who can run the query is the only person who knows where those tables live; he is competent, cooperative, and entirely unqualified to decide what falls inside the scope of a court order. By Monday he has exported everything the request mentions, plus a few adjacent fields, because leaving them out felt like hiding something.

That export is now the company's biggest privacy problem, and no one in the building thinks of it that way. They think they complied.

What actually landed in New York

On August 20, Take-Two Interactive filed two subpoenas in the Southern District of New York seeking to identify the person or persons behind a persona that has been publishing Grand Theft Auto VI material. The filings were made under Section 512(h) of the Digital Millennium Copyright Act, a mechanism that lets a rights holder obtain a subpoena from a court clerk without first filing a lawsuit. Take-Two's counsel submitted a sworn declaration stating that the purpose is to obtain the identity of an alleged infringer and that the information will be used only to protect its rights. Both recipients were given until September 4.

The scope, as reported from the filed documents, is what makes the case instructive. From Microsoft: internal business and investigative records from its own inquiry into the persona, account IDs, registration and last-login IP addresses, phone numbers, device identifiers including MachineGuid and MSA values, linked Google and Xbox connections, and OneDrive contents referencing certain terms. From Discord: identifying information for all accounts that were members communicating in several named servers from June 1 to the present, plus associated device and telemetry records.

One of the named servers reportedly belongs to a well-known content creator who publicly stated he knew nothing about any of it. Whether or not that turns out to be the whole story, it shows the structural problem. Requests like this are usually drawn around a container - a server, a channel, a date range, a filename pattern - because the requester does not yet know which individual they are looking for. That is the entire purpose of the exercise. Which means the people whose data sits inside the container are mostly bystanders.

The instrument has edges

Section 512(h) is not a general discovery tool, and its limits have been litigated. It authorizes an order requiring a service provider to disclose information sufficient to identify the alleged infringer. That phrase does real work. It is not a warrant, it is not a civil discovery subpoena issued in a pending action with a judge supervising proportionality, and it does not come with the breadth either of those would have.

In 2003 the D.C. Circuit held in In re Verizon Internet Services that a 512(h) subpoena can only be directed at a provider that stores the material on its own systems, not at one acting as a mere conduit, because the statute requires the request to be paired with a takedown notification identifying material the provider can actually remove. The Eighth Circuit reached the same conclusion two years later. Providers have been quashing and narrowing these subpoenas ever since.

The second edge matters more for most companies. The Stored Communications Act, 18 U.S.C. § 2702, generally bars providers of electronic communication and remote computing services from divulging the contents of communications to any person or entity, and the exceptions do not include civil subpoenas. Courts have said so repeatedly and without much hesitation. Non-content records - subscriber name, address, IP logs, session data - sit in a different category and can often be produced. Content does not. A cloud storage folder is content. A private message thread is content.

The consequence is the part most companies have backwards. A provider that produces content in response to a civil subpoena is not being cooperative. It may be violating a federal statute on behalf of a private party that had no right to compel it. Over-compliance is not a safe default. It is a second, separate exposure, and unlike under-compliance it is invisible until someone sues.

Where this stops being a story about two big platforms

Most companies reading this will never be Microsoft. Almost all of them run something with a container in it. A community forum. A customer Slack Connect channel. A support ticket system with attachments. A shared drive with client folders. A product with device telemetry that was switched on three years ago for a crash-reporting project since abandoned.

Any of those can receive a third party's demand for everything inside a boundary, and the population inside that boundary will include people with no connection to the dispute.

The compliance question is not whether you will respond. You will. The question is whether the response is produced by a process or by whoever happens to have database access on a Friday.

Four things that separate a defensible response from an exported CSV

A named owner, not a mailbox. Every organization has a legal@ address. Fewer have a person whose job description says they own service of process, with a backup named for vacation and a documented path to outside counsel who has done this before. Fourteen days is not a long time to also be figuring out who is in charge.

A scope triage done on paper before anything is queried. Three columns: what the instrument plainly compels, what it arguably compels, and what it asks for but cannot compel. Content almost always lands in the third column. So do records the request describes loosely. "Any associated device or telemetry records" is a phrase, not a defined field. Somebody has to translate the request into actual columns in actual tables, and the translation should be written down, because it is the record of your reasoning if the disclosure is later challenged by the person whose data it was.

A bystander filter as a hard rule. Produce the match, not the container. If a request covers everyone who posted in a workspace over ninety days, the defensible move is to identify the accounts responsive to the actual identifying purpose and to object or move to narrow as to the rest. Producing all four hundred because the subpoena said all four hundred is a choice, and it is the choice you will have to explain.

Preserve broadly, produce narrowly. These two get collapsed into one action all the time, and they are opposites. The moment a demand arrives, suspend deletion on anything plausibly relevant, including the routine retention job that runs overnight. Then argue about production separately and slowly. A company that deletes during the window has a spoliation problem. A company that produces everything it preserved has a privacy problem. Both are avoidable and the same afternoon of work prevents them.

Retention is the part you control in advance

Everything above is about a fortnight of pressure. The variable that actually determines the outcome was set years earlier, quietly, by whoever decided how long to keep things.

You cannot be compelled to produce what you no longer hold. A request covering June 1 to the present is only as damaging as the data behind that date. If registration IPs are retained for ninety days, the answer to part of the request is a short sentence. If hardware identifiers were never linked to accounts in the first place, another part of the request has no responsive material. If telemetry from an abandoned analytics project has been sitting in cold storage for four years because nobody wanted to be the person who deleted it, that project just became discoverable, and the people it describes never had any idea it existed.

Data minimization gets discussed as a regulatory obligation, which makes it feel like paperwork. The better argument for most executives is that it reduces the volume of other people's private information your company can be ordered to disclose. A retention schedule that someone actually enforces is the cheapest privacy control there is, and the only one that works retroactively.

Two traps worth naming

The first is the notice promise. Many platforms commit in a transparency policy or privacy notice to telling users before disclosing their data in response to legal process, with carve-outs for sealed orders and emergencies. It is a good commitment. It is also a statement of fact about your practices, and failing to honor it in a rush is a deception exposure under Section 5 of the FTC Act and under state consumer protection statutes, entirely separate from the underlying privacy question. If your policy says you notify, build notice into the response workflow, and document the reasoning on the occasions when you do not.

The second is misreading the legal-obligation exemption. Every U.S. state comprehensive privacy law, from the CCPA onward, permits a controller to disclose personal information to comply with legal process. But the exemption tracks the process. It covers what the instrument compels. Volunteering data outside the compelled scope is not compliance with a legal obligation, it is a disclosure that has to stand on its own footing under whatever notice, purpose limitation and consumer-rights framework applies to you. The individual whose records were produced can still submit an access request afterward and ask what you handed over and why. Your triage document is the answer to that question or it isn't.

The other side of it

None of this argues for reflexive resistance, and a compliance function that treats every demand as an attack fails in a different direction. Section 512(h) exists because there is otherwise no practical way to identify an anonymous infringer before filing suit, and rights holders have a legitimate interest that courts protect. Recipients who stonewall properly issued process collect motions to compel, cost awards and sanctions, and they earn every one of them.

This is not obstruction. It is the ability to tell the difference between what a document demands and what the law behind it authorizes, and to make that call quickly, in writing, with a named person accountable for it. Companies that can do that respond faster than companies that cannot, because they are not arguing internally while the clock runs.

Back to Friday

The company in the opening scene did not have a bad lawyer or a careless engineer. It had no process, and process is the only thing that converts fourteen days of pressure into a set of decisions someone can defend a year later.

The subpoenas filed in New York will resolve however they resolve, and the outcome barely matters here. Somewhere in your systems is a container full of other people's data, held longer than anyone remembers deciding, waiting for a demand drawn around its boundary. It is worth knowing what is in it before someone else asks.

We help companies build the part that comes before the deadline: retention that someone enforces, a named owner for legal process, and a documented method for deciding what a demand actually compels. If you are not sure what your systems would produce on a Friday afternoon, that is the conversation to have.