Responsive Records

Scoping is the least glamorous step in request handling and the one where most avoidable harm occurs. The legal analysis is usually settled by the time you get here. What remains is a careful reading.

What makes a record responsive

A record is responsive when it falls within the request’s defined scope, which is normally bounded on several axes at once:

  • Identifier: the specific account, user, device, or address named
  • Time: the date range specified
  • Data type: subscriber information, transactional records, or content
  • Legal ceiling: what the instrument is actually capable of compelling

That last axis is the one most often forgotten. A request may ask for content while attaching a subpoena. The content is within the request’s stated scope and outside the instrument’s authority, which means it is not responsive in any sense that matters.

The two failure modes

Under-productionOver-production
What happenedResponsive records withheldNon-responsive records disclosed
Who is harmedThe investigationThe user
Detected whenAgency follows up, or in litigationOften never
ConsequenceNon-compliance, possible contemptUnauthorised disclosure of user data

The asymmetry in the “detected when” row is why over-production persists. Nobody complains. The agency received more than it asked for and has no reason to object; the user does not know. A programme that only corrects the errors somebody notices will drift steadily toward over-disclosure.

How to scope well

  • Read the instrument before the cover letter. The instrument sets the ceiling.
  • Write the scope down explicitly before searching: identifiers, date range, data types.
  • Search to that scope, rather than searching broadly and filtering afterwards. Broad retrieval followed by filtering makes over-production a slip rather than a decision.
  • Resolve ambiguity in writing with the agency, and keep the reply.
  • Record what was produced and why. A production log is the only way to answer questions about a request months later.

Why this matters beyond compliance

Every unnecessary record disclosed is a user’s data that left the company without legal compulsion. Users cannot audit this. They generally do not know a request occurred, and where a non-disclosure order applies they are not permitted to. The discipline of tight scoping is one of the few protections that operates entirely on the user’s behalf, exercised by a company they will never discuss it with.

Frequently asked questions

Who decides what is responsive?

The recipient does, reading the request’s scope against what it actually holds. The requesting agency defines the scope; the company determines which of its records fall inside it. That judgement sits with the company, which is also why it carries the consequences of getting it wrong.

What if a request is ambiguous about scope?

Ask the issuing agency to clarify in writing, and produce against the clarified scope. Resolving ambiguity by producing generously is the wrong default. It discloses user data that was never properly compelled, and the written clarification is also the record protecting the decision.

Is it acceptable to produce more than was asked for?

No. Over-production discloses data the requester had no authority to obtain and that the user did not have to surrender. It is not a neutral act of helpfulness; it is an unauthorised disclosure, even though the underlying request was legitimate.

See what
we can do
for you.

Request a demo