Direct answer
Say no to the artifact (the raw logs) and yes to the need (understanding the discrepancy). You decline in one sentence, give the reason in terms the contact cares about, and in the same breath offer something that answers their real question faster than a log dump would. A contact who asks for raw logs usually wants proof that the numbers are right, not the logs themselves.
What I would say
"I can't send the raw query logs. They contain activity from other users and other customers' systems, and exporting them from the live store slows down the service for everyone. What I can do is get you what you actually need to settle the discrepancy. Can you tell me which two numbers disagree, for which dates, so I can build you a reconciliation that shows exactly where they diverge? You'll have it by end of day Thursday, and I'll walk you through it on a 20-minute call if that's useful."
Why this wording: the refusal is short and not apologetic, the reason is about protecting them (privacy) and their service (performance), and the very next sentence is a concrete offer with a date.
Step 1: find the real question (before offering anything)
Ask: "What decision or report is this discrepancy blocking?" and "Which figure do you trust, and which looks wrong?" Often the contact needs one of three things: proof the totals are right, an explanation of a gap, or evidence for their own auditor. Each needs a different, smaller deliverable than raw logs.
Step 2: offer a ladder of alternatives, safest first
| Offer | What the client gets | Why it is safe |
|---|
| Reconciliation summary | A table bridging their number to ours (counts by day, by status, by reason a row was excluded) | Aggregates, no individual records |
| Scoped, redacted extract | Only their own account's queries for the disputed window, with user identifiers and query text masked | Limited to their tenant (their own isolated slice of the data), reviewed by security first |
| Live walkthrough | A screen-share where I run the investigation queries with them watching | Nothing leaves our environment |
| Documented definitions | How each metric is counted (time zone, filters, deduplication) | No data at all |
Whichever you offer, check with your security or privacy contact first that the extract is allowed under the customer's agreement (usually a data processing agreement, the contract that says what data may be shared and how). Run any export on a copy or at off-peak hours so it cannot hurt live performance.
Worked example
The client says their finance report shows 1,204 queries for last Tuesday and our usage page shows 1,150. A raw log would hand them every query line for the day, including other users' activity, for them to sift and count themselves. Instead I send a bridge: 1,204 (their count) minus 31 queries from a scheduled job that our page excludes by design, minus 15 that fall after midnight UTC but before midnight in their time zone, minus 8 that were retried and counted once by us = 1,150. Check: 31 + 15 + 8 = 54 and 1,204 - 54 = 1,150. These numbers are illustrative. The point is that three sentences of explanation settle what a log export never would.
Trade-offs and pitfalls
- Do not say "company policy" and stop. It sounds like hiding something and invites escalation to your manager.
- Do not over-explain the technical reasons. One privacy reason and one performance reason is enough.
- Do not promise a deliverable you have not cleared. Offer the summary now, and treat the redacted extract as "I will ask, and tell you by Friday".
- If the contact is persistent after the summary, escalate the access question to the account owner and security together instead of arguing alone. If their auditor legitimately requires record-level evidence, that goes through a formal request, not an informal export.
