Incident response

Three levels, defined by impact

A single failing data source is normally Sev-3 by design: sources run in isolation so that one provider cannot take the system down, and the failure is shown publicly on the sources panel while everything else continues.

Any suspected unauthorised access is treated as Sev-1 from the first minute, before it is confirmed, so that notification deadlines are not missed while it is being investigated.

Severity is set by impact rather than by who reported it. If you believe something has been graded too low, tell us and it will be regraded.

Four sources of detection

1. Automated monitoring, described under availability: health checks, per-source run records, scheduled-job health, and the data integrity checks. State changes are delivered to the on-call channel with a daily summary of anything still open.
2. Customer reports, which are not treated as lower priority than automated detection. support@vaethra.com, or the enterprise phone line for a Sev-1.
3. Security researchers — security@vaethra.com. See vulnerability management.
4. Provider notification. Cloudflare and Supabase both notify us of incidents affecting our services and publish their own status pages.

Six steps

1. Declare and classify, within the acknowledgement window, stating what is known so far including where the cause is not yet known. Declaring starts every deadline on this page.
2. Contain before diagnosing. Disable the affected path, roll back the deployment, or revoke the credential. Diagnosis follows containment.
3. Notify. Affected enterprise customers within 24 hours of classification, by email and, for a Sev-1, by phone. Where personal data may be involved, the 72-hour requirement below applies in parallel.
4. Investigate. Establish the cause, the scope and the time window. Preserve logs and evidence before changing anything that would remove them.
5. Remediate and verify against the running system rather than against a test.
6. Report. A written post-incident report within 5 business days: what happened, the cause, what was affected, what was done, and what has changed to prevent recurrence.

Notification within 72 hours

Where an incident involves unauthorised access to systems or data, affected customers and any relevant supervisory authority are notified within 72 hours of Vaethra becoming aware, in line with GDPR Article 33. Vaethra is established in the United States and has no lead authority of its own: as a processor, we notify the customer, and the customer notifies the authority with jurisdiction over them.

The notice covers, per Article 33(3), the nature of the breach, the categories and approximate number of data subjects and records concerned, the contact point, the likely consequences, and the measures taken or proposed.

Because there are no user accounts, the personal-data surface is small: API key records and business contact details. We will nonetheless notify on any confirmed unauthorised access to production systems, whether or not personal data was involved, so that customers can make their own assessment of the risk.

Where a customer has its own regulatory reporting obligation — NIS2, DORA, or a sector regulator — the 24-hour customer notice is set to leave time inside their deadline. If your deadline is shorter, we will agree it in the contract.

Hourly updates on a Sev-1, with or without news

• During a Sev-1 you receive an update every hour, including when the content is that work is continuing.
• Enterprise customers receive updates from a named person rather than a queue address.
• Service failures appear on status and material incidents are added to the changelog.
• An incident is not described as resolved until it has been verified resolved against the running system.

Every report ends with a change

A post-incident report is required to close with a concrete change: a code change, a new automated check, or a documented decision. In this system it is usually the second.

The automated integrity checks described under availability are the accumulated output of this process. Each one exists because a specific failure was found that had reported success, and each now detects that failure the next time it occurs.

Reports are provided to affected customers, and the record of them forms part of the evidence pack available under NDA.