data-export-deletion-policy

Kitchen Toolkit — Data Export & Deletion Policy

Last updated: 2026-03-21 [source: docs/legal/data-export-deletion-policy.md]

## Exports
- Admins can export tenant data via `/api/exportTenantData`, which returns CSVs for logs (timestamps, deviceId, restaurantId, type, payload), CSVs for equipment (IDs, types, tenant references), alert key/value pairs, tenant profile fields, and masked environment variables. [source: pages/api/exportTenantData.js]
- Logs are stored with tenant-scoped keys (`log:{tenant}:{type}:{device}:{timestamp}`) and include server-trusted timestamps, client-local timestamps, HMAC signatures, and originating IPs for auditability. [source: pages/api/uploadLog.js]
- Equipment telemetry and alert records are stored in tenant-specific KV namespaces and can be exported through the same admin endpoint. [source: pages/api/uploadEquipmentLog.js][source: pages/api/exportTenantData.js]
- Admin UI pages surface logs, alerts, equipment, and notifications for viewing/export; admin exports come from authenticated API handlers, while crew CSV/log email exports currently send through KT-managed outbound mail infrastructure. [source: pages/admin/index.js][source: pages/index.js][source: pages/api/exportTenantData.js][source: pages/api/sendLog.js]
- Tenants may point telemetry to their own KV storage using `storage_kv_url`/`storage_kv_token`; exports will reflect data stored in that endpoint. [source: lib/tenant/env.js][source: pages/admin/settings.js]
- KT does not maintain separate backups of tenant KV data; exports pull from the live KV endpoint configured for the tenant. [source: docs/reference/data-and-privacy.md]

## Deletion
- Restaurant content (including precache copies) can be deleted via `/api/deleteRestaurant`, which removes tenant restaurant folders, icons, and manifest entries in Git-backed storage. [source: pages/api/deleteRestaurant.js]
- Deletion operations do not rewrite historical Git commits; removed content stays in repository history and must be treated as non-recoverable from the dashboard after deletion. [source: pages/api/deleteRestaurant.js][source: pages/api/buildRestaurant.js]
- `/api/deleteTenantData` deletes operational tenant records from the tenant-configured storage KV (or default KV if no override is configured) and deletes tenant profile/env/audit records from the platform KV. [source: pages/api/deleteTenantData.js][source: lib/tenant/storage.js]
- Log, alert, and live node-presence retention is enforced through KV TTLs (`LOG_RETENTION_DAYS`, `ALERT_TTL_DAYS`, `NODE_LAST_SEEN_TTL_DAYS`, `STALE_ALERT_TTL_DAYS`), with per-tenant overrides available in admin settings; tenants may adjust or delete data at any time without prior notice. [source: pages/api/uploadEquipmentLog.js][source: lib/tenant/env.js][source: docs/reference/retention-policy.md][source: docs/reference/data-and-privacy.md]
- Manual logs, hub heartbeats, and retained node last-value snapshots do not expire automatically; node snapshots are deleted by node/equipment detach or delete flows, and the other records must be deleted manually if required. [source: docs/reference/retention-policy.md][source: pages/api/admin/detachHubNode.js][source: pages/api/updateEquipment.js][source: pages/api/deleteEquipment.js]
- If a customer-managed KV provider, Git provider, email provider, or webhook destination maintains independent backups, archives, or message retention outside KT, those copies are outside KT’s direct control. [source: lib/tenant/storage.js][source: pages/api/deleteTenantData.js][source: pages/api/deleteRestaurant.js][source: lib/tenant/mailer.js]

## Restaurant bundle personal data audit (2026-03-22)

**Finding:** Restaurant bundle files committed by `pages/api/buildRestaurant.js` consist of the files uploaded by the admin (icon images, `index.html`, `app.js`, `style.css`, `metadata.json`) plus an auto-generated `restaurants.json` manifest. KT does not enforce a content schema on these files — operators control what content is written into them. The commit message includes the `tenantId` and `restaurantName`, but no contact information or personal data is required or automatically injected by the API. [source: pages/api/buildRestaurant.js]

**Risk:** If an operator manually includes staff names, contact details, or other personal data in restaurant content files (for example, in `metadata.json`), that data will be committed to the Git-backed store. Subsequent calls to `pages/api/deleteRestaurant.js` remove the active files but do not rewrite Git history. A right-to-erasure request covering personal data in such files cannot be fully honoured through the product's delete flows alone. [source: pages/api/deleteRestaurant.js]

**Recommendation:** Operators should not include personal data in restaurant bundle content. Document this expectation in any data-mapping exercise or DPA appendix. If personal data is suspected in committed history, contact the Git provider (GitHub) directly for history-rewriting assistance, or treat the Git history as a separate data store outside KT's direct control. This limitation is documented in the Privacy Notice. [source: docs/legal/privacy-notice.md]

## Notes and current limits
- Environment variables are stored encrypted and returned masked; exports intentionally avoid exposing full secrets. [source: lib/tenant/env.js][source: pages/api/exportTenantData.js]
- Password reset links, two-factor codes, alert emails, and some export emails may be sent through tenant-configured SMTP or KT-managed fallback/platform mail paths, depending on feature and configuration. KT’s standard product email flows are operational/account/reporting flows, not a general-purpose marketing platform. [source: lib/tenant/mailer.js][source: pages/api/auth.js][source: pages/api/tenant/requestPasswordReset.js][source: pages/api/sendLog.js][source: pages/api/uploadEquipmentLog.js][source: pages/api/admin/checkNodeHealth.js]
- Export/deletion flows are implemented as admin API calls without additional confirmation steps beyond the UI; support response targets and RMA handling live in the Support & SLA doc. Direct requests to liam@liambendix.com. [source: pages/api/exportTenantData.js][source: pages/api/deleteRestaurant.js][source: docs/leadership/reference/support-and-sla.md]
- KT does not monitor or retain copies of tenant secrets beyond the configured KV; customers are responsible for rotating credentials after suspected compromise. [source: lib/tenant/env.js][source: pages/api/tenant/requestPasswordReset.js]
- Security incident notifications will be sent to tenant contacts by email without undue delay after KT confirms or reasonably suspects unauthorized access, in accordance with applicable law and law-enforcement constraints. [source: docs/legal/terms-of-service.md]
- Subprocessor additions or changes will be communicated to tenant contacts at least 30 days in advance when practical (or promptly thereafter if urgent for security/legal reasons). [source: docs/legal/terms-of-service.md]
---
audience: legal
scope: legal
tenantId: global
version: production
status: current
rag.importance: normal
rag.preferredPaths: ["/pages/**", "/pages/api/**", "/public/js/restaurantLoader.js", "/public/sw.js", "/firmware/**"]
last_verified: 2026-03-21
---