Kitchen Toolkit documentation

incident-response-runbook

docs/legal/incident-response-runbook.md

Kitchen Toolkit — Incident Response Runbook [source: docs/legal/incident-response-runbook.md]

Last updated: 2026-03-22 (revised: added GDPR Art. 33 72-hour supervisory authority notification requirement to Section 4) [source: docs/legal/incident-response-runbook.md]

This runbook covers suspected compromise of Kitchen Toolkit-hosted systems, tenant data, or customer-specific credentials managed through the product. It is grounded in the current hosted architecture (Vercel + Upstash by default, private GitHub repo, tenant-scoped secrets/env records) and the notice commitments already stated in the Terms and Security statement. [source: docs/legal/security-and-infrastructure.md][source: docs/legal/terms-of-service.md][source: docs/reference/data-and-privacy.md]

## 1. Trigger conditions
- Treat any confirmed or reasonably suspected unauthorized access to KT systems or tenant data as a security incident, including compromised admin sessions, stolen device secrets, exposed tenant env credentials, suspicious writes to tenant-scoped KV records, or unauthorized access to hosted support sessions/attachments. [source: docs/legal/terms-of-service.md][source: lib/auth/session.js][source: lib/auth/device.js][source: lib/tenant/env.js][source: pages/api/support-bot.js]
- Also trigger this runbook when operators reasonably suspect compromise of the hosted platform itself, because KT’s current posture allows temporary service suspension while patches are applied. [source: docs/legal/security-and-infrastructure.md][source: docs/legal/terms-of-service.md]

## 2. Immediate containment
1. Stop active exposure first: suspend or take down the Vercel deployment if needed, disable affected workflows, and prevent further writes while triage is in progress. [source: docs/legal/security-and-infrastructure.md][source: docs/legal/terms-of-service.md]
2. Rotate or revoke the credentials in scope: admin passwords via reset flows, device secrets via the Device Secrets tools, and tenant SMTP/webhook/KV credentials through `/admin/settings` or direct provider rotation if compromise is suspected. [source: pages/api/tenant/requestPasswordReset.js][source: pages/api/tenant/resetPassword.js][source: pages/api/admin/devices.js][source: pages/admin/settings.js][source: lib/tenant/env.js]
3. Preserve the available evidence before overwriting it: note affected tenant IDs, approximate timestamps, IP addresses, changed environment fields, device IDs, and any support-session identifiers while the data still exists in KV-backed audit/history records. [source: pages/api/updateTenantEnv.js][source: lib/auth/device.js][source: pages/api/support-bot.js]

## 3. Investigation checklist
- Check the hosted dependencies involved in the incident: Vercel for deployment/runtime exposure, Upstash for KV-backed records and nonce/audit state, GitHub for source/content changes, Stripe for billing metadata issues, and any customer-configured SMTP/webhook/KV endpoints touched by the affected tenant. [source: docs/reference/data-and-privacy.md][source: docs/legal/privacy-notice.md][source: lib/tenant/env.js][source: lib/billing/stripe.js]
- Review tenant-scoped auth and audit surfaces: signed admin cookies and CSRF protection, device HMAC/nonces, masked env reads, env update audit entries, and any log/export paths the incident may have touched. [source: lib/auth/session.js][source: lib/auth/csrf.js][source: lib/auth/device.js][source: pages/api/getTenantEnv.js][source: pages/api/updateTenantEnv.js][source: pages/api/exportTenantData.js]
- For `/help` incidents, review temporary support-session history and attachment publication behavior, because help-session history is cached in Upstash and attachment-image URLs are short-lived but externally reachable while valid. [source: pages/api/support-bot.js][source: lib/agent/attachmentImageStore.js][source: docs/legal/privacy-notice.md]

## 4. Customer notice and regulatory reporting
- When KT confirms or reasonably suspects unauthorized access to KT systems or tenant data, notify the affected tenant contacts by email without undue delay, subject to applicable law and law-enforcement constraints. [source: docs/legal/terms-of-service.md][source: docs/legal/security-and-infrastructure.md]
- Include the tenant/account scope, what categories of data or credentials may have been involved, what KT has already disabled or rotated, what customer-side actions are recommended next, and whether service availability is temporarily affected. [source: docs/legal/terms-of-service.md][source: docs/legal/privacy-notice.md][source: docs/legal/security-and-infrastructure.md]
- **GDPR Art. 33 — supervisory authority notification:** If the breach affects personal data of EU residents and is not unlikely to result in a risk to individuals' rights and freedoms, notify the relevant supervisory authority **within 72 hours** of becoming aware of the breach. This clock runs from the moment KT becomes aware of the incident, not from the moment it is fully confirmed. If the 72-hour deadline cannot be met, submit an initial notification and follow up with supplementary information. Note that the 72-hour authority clock and the "without undue delay" tenant-notification obligation run simultaneously and independently — do not wait for one before starting the other. Counsel review is recommended before the first notification. [source: docs/legal/terms-of-service.md][source: docs/legal/privacy-notice.md]

## 5. Recovery and follow-up
- Patch the root cause, restore service only after the immediate exposure is closed, and monitor for repeat access or failed-auth anomalies after bringing the deployment back online. [source: docs/legal/security-and-infrastructure.md][source: lib/auth/session.js][source: lib/auth/device.js]
- Ask affected customers to rotate any third-party credentials they supplied to KT (SMTP, webhook, or custom KV credentials) if those values may have been exposed, because KT stores and uses them on the customer’s behalf but customers remain responsible for the connected services themselves. [source: docs/legal/terms-of-service.md][source: lib/tenant/env.js][source: pages/admin/settings.js]
- Update the legal/security docs when the hosted architecture, notice commitments, or supported recovery steps change so this runbook stays aligned with the codebase and contractual language. [source: docs/legal/security-and-infrastructure.md][source: docs/legal/privacy-notice.md][source: docs/legal/terms-of-service.md]