Playbook, developer tools company
Two deployments, and two completely different answers to delete our data
This request splits before it can be answered. A customer running the software on their own infrastructure is asking about data that never reached you, and the honest reply says so and points at whoever operates their deployment. A customer on the hosted service is asking about request logs, telemetry and whatever payloads got captured during a debugging session, each with a separate clock. One paragraph for both is how you end up wrong twice.
Why this is not the general answer
The handling pattern for data deletion requests holds across every trade. What follows is the part that does not.
- Where the software runs on the customer's own infrastructure the content never left it, so the deletion is theirs to perform and what you hold is limited to licence, update and telemetry records. Saying that clearly is the answer rather than a deflection.
- Request logs are the awkward part. They exist for debugging, they routinely contain fragments of whatever was sent, and their lifetime was set by an engineering decision rather than by a policy anybody wrote down.
- Product telemetry is usually on by default with a documented way to switch it off, and the request underneath a good share of these messages is turn it off rather than delete what you already have.
- A credential is not personal data and it is still the thing people most want gone, and revoking one and deleting a record are separate operations that customers cover with a single word.
How it arrives
- we run it on our own servers what do you actually hold
- how long do you keep request logs
- does the tool phone home and can we switch that off
- delete the payloads you captured while we were debugging
- revoke every credential on our organisation and remove them
- what fields are in your telemetry
What has to be indexed for this to work
| A statement of what you hold for a self hosted install | Licence records, update checks, telemetry if there is any, support correspondence. Short, specific and dated. It answers most of this pair and almost nobody writes it, because it feels like a document that says nothing. |
|---|---|
| The retention window, given per class of log | Request logs, error traces and debug captures taken during an investigation all live for different periods, and the captures are commonly the longest lived because nobody ever set a rule for them. |
| What the telemetry contains and how it is disabled | The fields, the transport, the setting or variable that turns it off, and whether anything else stops working when it is off. Publish the field list, because a customer left to guess assumes the worst and writes to you about it. |
| The route for a formal request, and the period you commit to | Where it goes, what to include so it can be matched to an organisation, and how long a reply takes. Route it somewhere read daily, since the clock generally starts when a request arrives rather than when somebody notices it. |
The reply
It depends where the software is running. On a self hosted install your content stays on your own infrastructure and never reaches us, so what we hold is limited to the records in that statement, and the deletion itself is done by whoever operates your deployment [1]. On the hosted service, request logs are kept for the period in the retention note, and debug captures taken during an investigation are held separately with their own period stated there [2]. Telemetry can be turned off with the setting on that page, which is often what people are really asking for. I cannot delete anything, revoke a credential or tell you what is held for your organisation, so leave your name, an email and which of the two you are on, and it goes to the person who handles these.
Splitting on deployment in the first sentence is the whole job, because the two answers share no content at all. Naming debug captures separately is uncomfortable and necessary, since those are the records customers are most surprised to learn about. Offering the telemetry switch answers the request behind the request without anybody having to make a formal one.
Where it stops
The trigger. Any request to delete, export or revoke anything, and any question about what is held for a named organisation or account.
This is a request rather than a question, and nothing I do here touches a record anywhere. Leave your name, an email, your organisation and whether you are self hosted or on the hosted service, and you will get a reply inside the period set out in our privacy notice.
It stops answering before it guesses, says who will pick it up, and asks for the one thing that makes a reply possible. Nothing about it reads as a dead end.
Never say this here
Out of bounds
- Never say anything has been deleted, revoked or scheduled for removal, because nothing here writes to any system.
- Never state a log, capture or backup retention period that is not in your own published note.
- Never say a self hosted deployment sends nothing back, unless your telemetry documentation states exactly that.
- Never confirm whether a named organisation or address has an account with you.
Questions
- Can it revoke a leaked credential while somebody waits?
- No. It reaches no system at all, and revocation happens on your own screen or through your own interface. What it can do is say plainly that revocation is the immediate step, point at the page describing it, and take the details so somebody follows up quickly.
- Self hosted customers ask this constantly. Is one document really enough?
- One honest document covers almost all of it, provided it lists what you hold rather than what you do not. A statement written as a denial reads as evasion. Four record types with a period against each ends the conversation in a single reply.
- Should debug captures be published separately?
- Yes. A capture taken during an investigation outlives the investigation more often than anybody admits, and a customer who discovers that months later treats it as a finding rather than as a detail you had already written down.
Keep reading
- Everything for a developer tools companyOn a docs site an assistant competes with search, not a phone line. Version skew, deprecations and error strings decide whether it earns its place.
- Handling data deletion requests in generalA deletion request is a request with a clock on it, not a question. The characteristic failure is silence, so it always has to reach a person.
- An engineer has been handed a review and does not own the answersAudit logs, retention windows and release provenance. What can be answered from published trust material, and which rows need an agreement.
- Access problems where half the accounts do not belong to anybodyMachine identities, organisation membership and credentials shown only once. Access questions where the actor is a process rather than a colleague.
- The word reset covers two things here and one of them cannot waitRotating a credential without dropping traffic, and the first move when a token turns up in a public commit. Neither is a password reset.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.