Incident response and breach notification

What could be exposed

The tools run in your browser and never send the files you open, so a breach of this site cannot expose your documents: they are not here. What the service does hold is small, and this is all of it:

What	Where it is	What would expose it
Buyers' names, email and billing addresses, and cards	At Stripe, on Stripe's systems. This site never sees a card number.	A breach at Stripe, which Stripe would handle and report. Or this site's Stripe key leaking: depending on the permissions it was given, it can read subscriptions, checkouts, charges and customers, which hold buyers' names, email and billing addresses and the last four digits of a card, never a whole card number.
Seats on Team and Business: the names and email addresses an admin typed, and the record of changes	Workers KV, in this site's Cloudflare account.	Somebody getting into the Cloudflare account, or a flaw in `/api/seats` that hands one plan's seats to another's key.
Waitlist email addresses	Workers KV, the same store.	The same account, or the key that opens `/api/waitlist-export` leaking.
Licence records	None are kept: a key is a signed statement the buyer holds, and Stripe is the record of who paid. The store keeps notes of which checkouts were emailed, and invitation pairings, by Stripe reference with no names.	The signing key (`LICENCE_PRIVATE_KEY`, a secret in Cloudflare) leaking would let somebody make keys. That is a loss to this site, not an exposure of anybody's data, and it is handled the same way.
Emails, once email is switched on	Resend keeps what it sent: the address, and the key or invitation in the message.	A breach at Resend, or its key (`RESEND_API_KEY`) leaking. Email is not switched on today.
The site's own code	The repository on GitHub, deployed by Cloudflare Pages.	A change nobody meant, through a stolen GitHub or Cloudflare login. This is the serious one: changed code could try to send what a tool opens. The security policy limits where a page may send anything to this site itself, and the release list lets anybody check the files they were served against the ones published.

The page count holds no personal data: a date, a page's address, a word for what happened and a class of where the visit came from. The full list of what the server keeps is on Trust, and who else handles any of it is on the sub-processor list.

What happens

OBSCURA OS is run by one person. There is no security team and no rota; this is what that person does, in this order.

Stop it. Replace whatever leaked: the Stripe key, the signing key, the Resend key, the owner's keys for /stats and the waitlist export, and the GitHub and Cloudflare passwords and tokens. Take a broken route out of service, or take the change back, rather than wait for a fix.
Find out what it touched. The server keeps no access log of its own, so the record is what Cloudflare's dashboard and Stripe's log of requests made with the key show, and what the store holds. What could not be found out is said, not assumed to be nothing.
Tell people, as below, once it is known that personal data was or may have been exposed. Not after the fix: as soon as it is known.
Fix it, and write it down. Every breach is recorded, reported or not: what happened, what it affected, what was done, and when. The record is kept for at least two years. Once it is safe to, a plain account goes on Status.

Who is told, and when

Who	When	What they are told
A Team or Business customer, about its seats	Without undue delay after we become aware of it. For seat data the customer is the controller and we are its processor, so this is what the data processing agreement promises; the customer can then meet its own deadline to its regulator.	What happened, which of its records it affects, what is being done, who to ask, and what is not yet known.
The data protection authority	Where we are the controller (buyers, the waitlist) and a law requires it: under the GDPR or the UK GDPR, within 72 hours of becoming aware, unless the breach is unlikely to put anybody at risk; under Canada's PIPEDA, as soon as feasible where there is a real risk of significant harm. A report that cannot be complete in time is made in time and completed later.	What the law asks for: the nature of the breach, the people and records affected, the likely consequences, and what has been done.
The people whose data it is	Without undue delay, where the breach is likely to put them at high risk (a buyer's email address with their key, say). For seat data, the customer decides, and we help.	In plain words: what happened to their data, what it means for them, and what they can do.
Everyone	Once it is safe to say, so that publishing does not help whoever is still trying.	A note on Status, which stays up.

Stripe, Cloudflare and Resend each handle a breach of their own systems under their own terms. If one of them tells us of a breach that touches this site's data, the same clock starts for us that day.

How you are told

By email from [email protected], to the address the subscription was paid with (Stripe holds it), or the address on the waitlist. It never asks you for a password or a card number, and never asks you to sign in through a link to anywhere but obscuraos.com: there are no passwords here to ask for. A message that does is not from us.

If a message has to replace your key, it says so, and the new key also comes from the Pro page.

Reporting one

If you think something here has been exposed, or have found a way it could be, write to [email protected]. That is the contact in security.txt; the security page says what is in scope and how reports are treated. A report is acknowledged within three business days; that is a target, not a guarantee.

This policy was written on 1 October 2026. It has not been tested by a drill or reviewed by anybody independent, and it is not a certification.