🚨 Incident Response

How Tellia handles a security incident: a confirmed or suspected event that compromises the confidentiality, integrity, or availability of personal data or production systems.

Canonical source

The operational runbook lives at SECURITY.md in the repo root. This page mirrors it for the engineering handbook — keep the two in sync when either changes.

Why this exists

The Customer DPA (Annex II — Company Security Standards, §2.5) and DPA Section 10 (breach notification) commit Tellia to a documented incident-response process. This is that process — required for the KWS deal and future enterprise contracts.

When to involve Security

Trigger this process — notify the security lead or privacy@tell-ia.comimmediately — for any of:

• A secret is exposed anywhere it shouldn't be: committed to git, printed in logs, pasted in Slack, in a screenshot, or sent to the wrong person (API key, password, token, DB URI).
• Suspected or confirmed unauthorized access to production systems, the database, or an admin account.
• A device with access to production or customer data is lost or stolen.
• Personal data appears where it shouldn't: one customer seeing another's data, PII in logs/exports, or data sent to the wrong recipient.
• A sub-processor or vendor notifies us of a breach on their side.
• An account is compromised or phished (Google Workspace, GitHub, AWS, Atlas, Railway, 1Password).
• A customer reports their data may have been exposed or accessed without authorization.
• Production data is unexpectedly deleted, altered, or corrupted.
• An external party (researcher, customer) discloses a vulnerability.

When in doubt, report it

A false alarm costs minutes; an unreported breach costs the DPA. The security lead decides severity — reporters don't need to be sure first.

Roles

• Security lead / incident commander: Vincent Trastour (CTO), vincent@tell-ia.com. Owns severity classification and the notification decision; may delegate during an incident.
• Reporter: anyone who suspects an incident. Report immediately to the security lead or to privacy@tell-ia.com.

The process

1. Detect

Incidents surface from Sentry alerts (web, mobile), Grafana Cloud logs/metrics/ traces (backend via OpenTelemetry), vendor notifications, or reports to privacy@tell-ia.com. Whoever suspects an incident notifies the security lead immediately.

2. Triage — assign severity

Severity	Definition
SEV1	Confirmed unauthorized access to, or loss of, personal data or production systems.
SEV2	Suspected or attempted breach — not yet confirmed, or already contained.
SEV3	Minor; no personal data or production exposure.

Open a confidential issue in the private Security team in Linear, tag the severity (SEV1 / SEV2 / SEV3), and log timestamps from here on.

3. Contain (immediately, SEV1 / SEV2)

• Rotate affected secrets in 1Password (DB URIs, API keys, tokens).
• Revoke compromised sessions / access (Firebase, admin consoles).
• Isolate the affected system — stop the bleed before investigating.

4. Assess

Record in the incident issue: what data, whose, how much, root cause, and whether the exposure is ongoing.

5. Notify

Timelines run from confirmation.

• Customer personal data (Tellia = processor): notify affected Customer(s) without undue delay, per DPA §10.
• Tellia's own data (Tellia = controller): assess 72-hour notification to the lead supervisory authority (CNIL) under GDPR Art 33; notify affected individuals if high-risk (Art 34).
• Document the notification decision either way — including a reasoned decision not to notify.

6. Recover

Restore from MongoDB Atlas point-in-time backups if needed, redeploy clean, verify integrity, and confirm the hole is closed before restoring access.

7. Review

Within 5 business days of resolution, write up the timeline, root cause, fix, and prevention. Add the entry to the incident register.

Incident register

The authoritative register is the issue list of the private Security team in Linear — one issue per incident (date, severity, summary, status), as audit evidence for enterprise review. Sensitive detail (affected data, credentials, system internals) lives only there — never in this repository, the docs site, the public sub-processor page, or other shared documents.