← Ataski · Trust & security · DPA · Subprocessors

Approved 2026-10-07

Incident Response Policy

Owner: the founder, who is the incident commander for every incident. Approved: 2026-10-07. Review: annually and after every incident.

This is the policy layer. The operative runbook — definitions, triage, containment ladder, notification wording, evidence handling, post-mortem — is docs/legal/incident-response-plan.md, which is a customer-facing commitment. This page states what the company undertakes and where the obligations come from; the plan states what to do at 03:00.

1. Commitment

• Every security event is triaged the same day it is detected.
• For any incident involving Customer Data, affected customers (Controllers) are notified without undue delay and in any event within 72 hours of Ataski becoming aware. That is the served DPA §9. The 72-hour clock in GDPR Art. 33(1) is the Controller's own deadline to their supervisory authority; our notification exists to make theirs meetable, so it goes out on what is known, not on what is complete.
• Every incident gets a written post-mortem within 7 days of closure, and corrective actions become tracked issues rather than intentions.

2. Detection

Incidents surface through Bugsink (errors, authorization failures, novel exception classes), Better Stack (uptime and job heartbeats), the append-only audit log (anomalous actor types, cross-tenant attempts), customer reports to security@ataski.com (the one public contact for security, privacy, data-subject requests and procurement), sub-processor notifications, and the cost guardrails — a tripped per-tenant cap is investigated as a possible compromised credential, not only as a billing event.

3. Severity

• SEV-1 — confirmed or likely unauthorized access to Customer Data, active exploitation, or a full outage with data-loss risk.
• SEV-2 — a vulnerability with plausible exposure but no evidence of exploitation, a partial outage, or a vendor-side breach of unclear scope.
• SEV-3 — availability or integrity with no personal-data dimension.

The breach question — is personal data involved, and whose? — is answered explicitly and in writing at triage. If the answer is yes or unclear, the event is handled as a Personal Data Breach until shown otherwise.

4. Containment order

Stop as early as the incident allows: flip the feature flag off → trip the per-tenant cap or the global kill switch → rotate the affected credential and revoke the customer's OAuth grants → take the application offline by stopping the application containers on the production node (Caddy then answers every request with an error; DNS is not proxied, so there is no edge to switch). Availability is sacrificed before confidentiality, always.

5. Evidence

An incident timeline file is opened at triage and only ever appended to. Bugsink events stay unresolved until the post-mortem; relevant audit-log ranges are exported; no affected rows are deleted while the investigation is open — which the append-only audit log largely enforces on its own. Right-to-delete obligations keep running, and any erasure performed during an open incident is noted in the timeline.

6. Roles

There is one person. This policy does not claim a rotation, a 24/7 NOC, a one-hour response SLA, a dedicated security team or a forensics retainer. What it does claim — same-day triage, the 72-hour controller notification, the append-only evidence trail, the kill switches, and a named accountable human — is true today.

Before the first hire, name a backup incident commander. A one-person rota is not a rota; it is a single point of failure with a schedule.

7. Exercise

Annual tabletop, two hours, written up. Suggested first scenario, because it is the one the architecture is most exposed to: an OAuth refresh token for a customer's CRM is found in a public paste. Walk it end to end — detection, containment, which grants are revoked, which customers are told, what the post-mortem changes. The plan has never been exercised; a tabletop is the cheapest evidence of design effectiveness there is.

8. Regulatory context

GDPR Art. 33(2) obliges a processor to notify its controller without undue delay — that is the source of §1. CCPA obligations run through the Service Provider posture (docs/legal/dpa-template.md). Customer-facing deletion and access rights are served through /api/export and /privacy/optout.

9. Contact

Security reports, privacy and data-subject requests, and DPA / procurement questions all go to one address, security@ataski.com, which is read by the founder. Breach notifications to customers are sent from the same address. Billing and refunds keep their own address (see the Refund Policy).