In plain language
If something goes wrong with your data, we tell you — within 72 hours of knowing, and sooner if it's serious. We tell you before the investigation is finished rather than waiting to have a tidy story.
Section 10 is the honest part: we don't yet have a rehearsed internal runbook behind these commitments. They're what we will genuinely do, not what a process document guarantees.
This summary is for orientation only. The numbered sections are the policy.
Contents
Scope of this page
This page sets out what you can expect from us when a security or data incident occurs: how we classify it, when we'll tell you, what we'll say, and what we'll do.
It deliberately does not publish our internal procedures — escalation contacts, tooling, forensic method, or system-level detail. Publishing that would help an attacker more than it helps you. What's here is the commitment; the mechanics behind it are internal.
These commitments are contractual where our Data Processing Addendum applies to you. Section 10 of the DPA is the binding version; this page explains how it works in practice.
What counts as an incident
A security incident is any event that compromises, or has a realistic prospect of compromising, the confidentiality, integrity, or availability of the service or the data in it.
A personal data breach is a security incident leading to accidental or unlawful destruction, loss, alteration, or unauthorised disclosure of or access to personal data. Every personal data breach is a security incident; not every security incident is a personal data breach.
Examples of what we treat as an incident:
- Unauthorised access to customer data, whether by an outside party or by misuse of internal access.
- A defect causing one customer's data to be visible to another.
- Loss or corruption of customer data without a means of recovery.
- Compromise of credentials, signing keys, or encryption material.
- Malicious code affecting our infrastructure.
- A subprocessor notifying us of a breach affecting data we've entrusted to them.
The following are not incidents for the purposes of this page, though we may still tell you about them: unsuccessful login attempts, routine scanning and probing traffic, blocked attacks with no impact, and planned maintenance.
How we classify severity
Classification determines urgency, not whether we tell you. Anything confirmed as affecting your data gets a notification regardless of severity.
| Level | Meaning | Examples |
|---|---|---|
| Critical | Confirmed unauthorised access to, or exposure of, customer data. Cross-tenant data leakage. Compromise of authentication or infrastructure. | An attacker reaches the database; a defect exposes one customer's conversations to another. |
| High | Credible risk of data exposure not yet confirmed, or a vulnerability that would allow it if exploited. Data loss without recovery. | A serious authorisation flaw found before evidence of exploitation; irrecoverable loss of a data set. |
| Medium | A security weakness with limited or no exposure of data, or an incident affecting availability without touching confidentiality. | A vulnerability requiring conditions that don't currently exist; an extended outage. |
| Low | Minimal risk, no data affected, resolved without customer impact. | A misconfiguration caught and corrected before it could be exploited. |
We classify on the information available and revise as we learn more. An incident that starts as High and turns out to have exposed data is reclassified as Critical, and we'll tell you it changed.
Notification commitments
Personal data breach
Where a personal data breach affects personal data we process on your behalf, we will notify you without undue delay and within 72 hours of becoming aware of it.
“Becoming aware” means having a reasonable degree of certainty that a breach has occurred — not the moment a possibility is first raised. We won't use that as a delaying tactic: where we suspect a breach and are still confirming, we would rather tell you early and update you than sit on it.
Critical and High severity incidents
We aim to make initial contact within 24 hours of classification, whether or not personal data is confirmed as affected. If your data might be involved, you should hear from us while we're still working it out.
Medium and Low severity incidents
Notified where relevant to you, typically as part of routine communication rather than an urgent alert.
How we reach you
By email to the account administrators and, where set, the billing contact on your account. For widespread incidents we may also post in the admin portal. Keeping your contact details current is your responsibility — we can only notify the addresses we hold.
We will not wait for a complete picture. The failure mode we're guarding against is the one where a company knows something is wrong on day one and tells customers three weeks later with a polished statement. You'll get the incomplete version first.
What a notification contains
To the extent known when we write it:
- What happened, described plainly.
- When it occurred and when we became aware.
- The categories and approximate number of data subjects and records affected.
- Whether your account specifically is affected, and how.
- Likely consequences.
- What we have done and are doing to contain and remediate it.
- What we recommend you do, including whether you may have notification obligations of your own.
- A named contact for follow-up.
Where something is still unknown, we say it's unknown rather than omitting it. We follow up as facts firm up, and send a closing summary once the incident is resolved.
What we do
Without detailing internal mechanics, our response follows a conventional shape:
- Detect and triage. Assess whether it's a genuine incident and assign a severity.
- Contain. Stop the immediate harm — revoking credentials, disabling an affected feature, blocking a route. Containment comes before investigation.
- Investigate. Establish what happened, what was reached, and how. Our audit log records administrative access to customer data, which supports this.
- Notify. On the timelines in section 4, in parallel with the work rather than after it.
- Remediate. Fix the underlying cause, not only the symptom.
- Review. Afterwards, examine what allowed it and what would have caught it sooner. Where the answer is a product change, it goes on the roadmap.
Your role as controller
For data processed through your widget, you are the controller and we are your processor. That division matters during an incident:
- We notify you. You notify regulators and data subjects if the law requires it. We can't do it on your behalf — we don't hold the relationship with your customers, and often don't hold the means to contact them.
- We will support your notification with the factual detail you need, and answer follow-up questions promptly.
- Assessing your own obligations is yours to do. Thresholds vary by jurisdiction and by the data involved.
- Incidents originating with you — a compromised staff account, a misconfigured integration, credentials shared inappropriately — are yours to handle. We'll help you understand what was reached, and our audit log is the tool for that.
Reporting an incident to us
Email security@desertdesk.app. Include what you observed, when, how to reproduce it if you can, and how to reach you. If it's urgent, say so in the subject line.
We acknowledge security reports within two business days, and faster for anything indicating active exposure.
Good-faith research
We welcome vulnerability reports. We don't run a paid bounty, but we will credit you if you want. Please don't access or modify data that isn't yours, degrade the service for others, or publicly disclose before we've had a reasonable chance to fix it. Research along those lines won't be treated as a breach of our terms. The full process is on our Trust Center.
If you suspect your own account is compromised
Change the password and revoke sessions immediately, review the audit log on your Users page for unfamiliar activity, and email us. Don't wait for confirmation before securing the account.
Incidents at a subprocessor
Where a subprocessor notifies us of a breach affecting data we've entrusted to them, we treat it as our incident. The same classification and notification commitments apply, and we remain responsible to you for their handling of your data under our Data Processing Addendum.
In practice our notification to you may depend on the detail they give us, and we will pass on what we receive and press for more where it's insufficient. Our current subprocessors are listed at desertdesk.app/subprocessors.
Current state
The commitments on this page are real, and the machinery behind them is thinner than you might assume. Desert Desk is operated by a very small team. We have not yet written and rehearsed a formal internal incident response runbook, we do not operate a 24/7 on-call rotation, and we have not run a tabletop exercise. What we have is a clear intention, a small enough system to understand thoroughly, and an audit log that records administrative access to customer data.
The practical implication: detection depends on monitoring and on reports reaching us, and a serious incident beginning at 2am on a Saturday will likely be noticed later than it would be at a company with a staffed rotation. Building the runbook is on our roadmap, tracked on the Trust Center.
We'd rather you knew this before choosing us than discovered it during an incident.
Contact
- Security reports and incidents
- security@desertdesk.app
- Data protection questions
- privacy@desertdesk.app
- Postal address
- Desert Desk LLC
[NOTICE ADDRESS]