Client and Customer-Facing Communication Questions

Direct answer

Share a one-page follow-up plan that says who owns each piece, the date by which the customer will hear from you (including interim updates, not only the final answer), and the exact deliverable that closes the question. Because legal and a vendor are both involved, you also own the coordination and must be explicit about what you can and cannot promise: you can commit to your process and dates, not to the legal outcome.

The plan as I would send it

Context: the customer asked whether our managed service can store personal data of EU residents in a way their compliance team accepts (for example, a question on data residency, meaning which country or region the data is physically stored and processed in; sub-processors, meaning other companies we use that handle the data on our behalf; and a data processing agreement, abbreviated DPA, which is the contract describing how a supplier handles the customer's personal data). For EU residents' personal data the main regulation is normally the GDPR, the EU General Data Protection Regulation.

Interim promise: "You will hear from me on Day 3 and Day 7 whatever the state, even if the update is 'still waiting on the vendor'." Then name an escalation: "If the vendor has not responded by Day 5 I will escalate through their account manager and tell you the same day."

What I would say in the covering note

"Thanks for your patience on the compliance question. Here is how I'll close it. I'm treating it as four sub-questions: where the data is stored and how it is protected; what the DPA must say; where the vendor's component processes data; and whether any data leaves the EU and on what legal basis. Technical facts come from me by Day 3. The legal and vendor positions can't come from me; I've asked both for written answers by Day 7 and I'll forward them unedited. On Day 9 you'll get one consolidated document that states what is confirmed, what is not, and your options. I won't characterise the legal position before legal has reviewed it."

Choices explained

• Separate what I own from what I do not. I own dates and coordination. I do not own the legal conclusion, and I say that so I do not imply a commitment I cannot make.
• Dated interim updates keep the customer from chasing. Silence is read as "forgotten".
• Define "closed" up front: a consolidated document plus a review call, so the question does not remain open indefinitely.
• Evidence over assertion. Attach documents, not summaries of documents.
• Name the possible bad outcome early. If the vendor cannot attest to EU-only processing, the customer should hear options (a different configuration, a contractual mitigation, or a non-starter) rather than a surprise on Day 9.

Trade-offs and pitfalls

• Padding dates for safety is better than hitting an optimistic date and missing; but padded dates that are too long stall the deal. Ask legal and vendor for their realistic turnaround before you publish the dates.
• Do not give legal advice or paraphrase legal conclusions yourself. Forward counsel's wording.
• Do not let the plan live only in email: record it in the account record so a colleague could continue if you are away.
• If the answer is unfavourable, say so as soon as you know; waiting for Day 9 to deliver bad news erodes trust.

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

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.

Direct answer

Acknowledge quickly, bring in your security team immediately, commit to process and to the next update time, not to a root cause (the underlying reason the flaw exists) or a fix date, and be factual rather than reassuring or alarming. At the executive meeting, say what you know, what you have checked, what you do not know yet and when you will tell them more. Offer interim steps the customer can take and that you can take now. Clear every sentence about the vulnerability with security and legal before it goes out.

Balancing openness against alarm

• Openness means facts and process. What was reported, what we have done, what we are checking, when the next update is.
• Alarm comes from guessing. Do not state a severity (a rating of how serious the flaw is), a cause or "no customers are affected" you cannot yet support. Do not write "there is no evidence of exploitation (attackers actually using the flaw)" unless you have actually looked and can say where you looked; say "we have checked X and found nothing so far, and we are still checking Y".
• Do not go silent. A promised update at a stated time, even "no change", is more reassuring than a late detailed one.

What I would do in the first hours

1. Thank the customer and get a way to reproduce it (trigger the problem again by following their steps), under their agreement to keep details confidential.
2. Hand the report to our product security team (the group that triages vulnerabilities, sometimes called PSIRT, the product security incident response team) and agree one owner and one customer contact.
3. Ask: is it reproducible, what data or systems are affected, is it being exploited? Do not tell the customer an answer to these until you have it.
4. Prepare the executive briefing with security and legal.

What I say at the executive meeting

"Thank you for flagging this. We take it seriously and our security team is investigating now. Here is where we are.
What we know: [what the customer reported, what has been reproduced].
What we have checked: [for example, logs for the affected endpoint over the last 30 days show no matching activity so far].
What we don't know yet: the root cause, and whether any other customer is affected. I don't want to guess about either.
What we commit to: an update by 10:00 on Thursday, whatever the status; a named contact on our side; and sharing the root cause and the fix when we have them.
What you can do now: [interim steps]. We will tell you if anything changes."

Interim steps to offer

What I commit to, and what I refuse to commit to

Commit to: response time, update times, one point of contact, sharing root cause and remediation once known, and following the company's coordinated disclosure process (agreed handling of when and how a vulnerability is made public). Refuse to commit to: a fix date before engineering has one, a severity rating before the assessment, "no impact", or anything legal has not cleared.

Trade-offs and pitfalls

• Pressure to say "it is fixed" at the meeting is high. Resist: a false all-clear that is later withdrawn is worse than an honest "not yet".
• Share exploit details only with those who need them. Wide circulation is itself a risk.
• If the customer is in a regulated sector, they may have their own deadlines to notify regulators; ask early so you know what clock they are on.