Incident and Breach Notification
In one line
What we do when something goes wrong with your data, and how fast we tell you and the regulators.
The short version
This short version helps you understand the full text. Read the full text for the complete terms.
- We have a written plan: contain, assess, fix, notify, and learn. (Full text, section 2)
- If a breach affects your workspace data, we tell you without undue delay, and within 48 hours of confirming it. (Section 3)
- Where we are the controller, we tell regulators within the deadline the law sets, for example 72 hours in the EU and UK, and 3 days in Singapore. (Section 4)
- We tell affected people directly when the law requires it, or when they need to act to protect themselves. (Section 5)
- We record every incident, even small ones, and publish a summary of significant ones on our change log. (Section 6)
Full text
Read the full text (about 2 minutes)
1. Definitions
An "incident" is any event that threatens the confidentiality, integrity, or availability of qypu or data in it. A "personal data breach" is an incident that leads to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.
2. Our response steps
- Detect and record. Anyone at qypu who suspects an incident reports it to the incident lead at once. We open a record with times.
- Contain. Revoke tokens, rotate secrets, block access, or pause publishing as needed.
- Assess. Find what happened, which data and people are affected, and the likely risk to them.
- Notify. Follow sections 3 to 5.
- Fix and recover. Remove the cause and restore service.
- Learn. Write a short review within 10 working days, with actions and owners.
3. Telling customers
Where a personal data breach affects Customer Personal Data, we notify the workspace owner without undue delay, and within 48 hours after we confirm it, with the information listed in the DPA section 7.2. We will help you meet your own notification duties.
4. Telling regulators (where we are the controller)
| Jurisdiction | Who | Deadline |
|---|---|---|
| EU and EEA | Lead supervisory authority | Within 72 hours of becoming aware, if there is a risk to people (GDPR Art. 33) |
| UK | ICO | Within 72 hours, if there is a risk to people (UK GDPR Art. 33) |
| Switzerland | FDPIC | As soon as possible, if there is a high risk (revFADP Art. 24) |
| Canada | OPC (and the CAI in Quebec) | As soon as feasible, if there is a real risk of significant harm (PIPEDA s.10.1; Law 25) |
| Singapore | PDPC | Within 3 calendar days of assessing a breach as notifiable (PDPA s.26D) |
| Australia | OAIC | As soon as practicable after assessing an eligible breach (assessment within 30 days) |
| New Zealand | Privacy Commissioner | As soon as practicable, if serious harm is likely (Privacy Act 2020 s.114) |
| United States | State attorneys general and residents | Under each state's breach law (deadlines vary, often 30 to 60 days) |
5. Telling affected people
We tell affected people directly, in plain language, when the law requires it or when they can take steps to protect themselves. We say what happened, what data was involved, what we are doing, and what they can do.
6. Platforms
If an incident affects data received from a platform, we notify the platform as its terms require (for example, Meta requires prompt notice of a security incident affecting platform data).
7. Transparency
We publish a short summary of significant incidents on the trust change log once it is safe to do so.
Change log
- 2026-10-10 · 0.1.0 · First draft.
Open questions for counsel
We publish these while the page is a draft, so you can see what is not settled yet.
- Confirm each deadline and threshold in the table, and the US state list once customers exist in the US.
- Confirm Meta and other platform incident notice terms.
Useful for: Business owners, IT and security reviewers. To save this page as a PDF, use your browser's Print command. Back to the trust centre.