Last reviewed: 2026-05-17.
1. Operating reality — read this first
We do not operate a 24×7 SOC. We are a small EU team; one operational owner is on call during EU business hours by default. Out-of-hours coverage is best-effort, not contractually guaranteed (see /sla). The DPA at /dpa §9 commits us to 72-hour breach notification regardless of headcount; this runbook is how we hit that commitment with the team we have, and the procedure scales without rewrite when we move to paged on-call rotation.
Honesty matters here. Pretending we run a SOC we do not run is the failure mode this page exists to prevent.
2. Severity classification
Severity is decided first; every subsequent step is severity-conditional. If unsure, we classify up, not down — a misclassified Sev 1 that turns out to be Sev 2 is recoverable, the reverse is not.
| Severity | Definition | Examples |
|---|---|---|
| Sev 1 | Service unavailable for all customers, OR confirmed unauthorized access to customer data, OR data loss with no recoverable backup. | Full outage. RLS bypass in production. Database lost. Confirmed credential theft. |
| Sev 2 | Core feature broken for many users; suspected (not confirmed) security incident; customer report of unauthorized access pending verification. | AI chat returning errors. Auth flow broken for new sign-ups. Customer reports seeing another tenant’s project name. |
| Sev 3 | Non-critical feature broken; small subset of users affected; security issue with no customer-data exposure. | Email delivery failing for one provider. Stale cache. Low-severity dependency advisory. |
| Sev 4 | Cosmetic, documentation, low-impact. | Typo on a page. Slow load on a non-critical route. |
3. Detection
Signals monitored today:
- Application errors — EU-hosted error monitoring sub-processor, real-time across every Next.js app.
- Cron failures — GitHub Actions + provider cron logs, per run.
- Auth provider alerts — managed authentication dashboard + email (account lockouts, MFA reset spikes).
- Billing anomalies — payment processor dashboard (refunds, disputes, chargebacks).
- Cost spikes — vendor billing alerts (LLM tokens, hosting bandwidth).
- Customer reports — security@lovex.dev and in-product chat, operator-checked.
Gap we accept today: no 24×7 paged alerting on application error spikes. A nighttime incident may not be acknowledged until business hours. This is documented in /sla and disclosed in the pre-answered security questionnaire.
4. Triage (target: 30 minutes for Sev 1)
When a signal fires:
- Acknowledge. Note the time the signal was first observed. This is the GDPR 72-hour clock start if the incident affects personal data.
- Classify severity using the table above.
- Open an incident ticket. Required for audit trail — done even at 3am.
- Decide if it is a security incident. If any plausible unauthorized access to customer data is possible, treat as Sev 1 until ruled out.
5. Containment (Sev 1 / Sev 2)
Stop the bleeding before chasing the root cause. We maintain a kill-switch inventory internally for compromised credentials, sessions, runaway AI cost, sub-processor breach, and hostile actors at the auth layer. Internal specifics (vendor consoles, rotation paths) stay internal under the security-by-obscurity-of-procedure principle; the existence of the kill switches is what we commit to publicly.
6. Customer notification — 72-hour clock
GDPR Article 33 commitment. If a personal data breach affecting customers is confirmed, we notify the customer within 72 hours of becoming aware. This is also the contractual commitment in /dpa §9.
Notification is sent to workspace owners of every affected tenant by direct email. Each notification states what happened in plain English, the scope, the time window, containment actions completed, investigation status, remediation timeline, and customer-side actions we recommend. Where we do not have full information at the 72-hour mark, we send what we know and follow up with a written update.
7. Regulator notification
GDPR Article 33 — supervisory authority. Personal data breaches are notified to Integritetsskyddsmyndigheten (IMY) within 72 hours of becoming aware unless the breach is unlikely to result in a risk to natural persons. We file via IMY’s online form with the required content: nature of the breach (categories and approximate numbers of data subjects and records), contact point, likely consequences, measures taken. If full information is not available at the 72-hour mark we file with what we know and supplement.
GDPR Article 34 — data subjects. Where the breach is likely to result in a high risk to the rights and freedoms of data subjects, we notify the affected data subjects directly without undue delay.
NIS2.The NIS2 Directive applies to “important entities” at 50+ employees or €10M turnover. Lovex does not currently meet either threshold; we revisit at scale-up triggers. We do not pretend NIS2 obligations apply when they do not.
8. Remediation
Root cause fix, verified in staging, deployed via the normal change-management workflow (local pnpm verify + PR review + staged rollout). No emergency cowboy commits without a written reason in the post-mortem. Every fix ships with a regression guard — a test, lint rule, schema constraint, or runtime assertion that prevents the same class of issue from recurring.
9. Post-mortem
Written document, completed:
- Within 14 days for Sev 1.
- Within 30 days for Sev 2.
Each post-mortem covers: summary, full timeline, impact (data subjects affected, customer-visible downtime, personal data categories, financial impact), root cause (the system condition that permitted the failure — not “human error”), what we changed, regression guards added. Stored internally and available to affected customers under NDA on request.
10. Continuous review
The internal runbook is reviewed quarterly and after any Sev 1 event. Material changes — new sub-processor, new kill switch, change to a notification commitment — are reflected on this page on next deploy.
11. Contact
Security incidents / disclosures: security@lovex.dev — see /security/disclosure for safe-harbor terms.
Privacy / data-subject requests: privacy@lovex.dev.