Kitchen Toolkit — Standard Data Processing Addendum (Template)

# Kitchen Toolkit — Standard Data Processing Addendum (Template)

_Last updated: 2026-03-22_ [source: docs/legal/data-processing-addendum.md]

- This template is Kitchen Toolkit's standard starting DPA for customer privacy reviews. It is meant to be completed and signed together with the applicable order form or subscription paperwork; until then, the Terms of Service and Privacy Notice remain the operative public baseline. [source: docs/legal/terms-of-service.md][source: docs/legal/privacy-notice.md][source: pilot-order-form.md]
- The template below only states positions the repository can support today: hosted SaaS delivery, tenant-scoped storage, documented subprocessors, bounded help-attachment caching, and the export/deletion/security flows already implemented in code and public docs. [source: docs/legal/privacy-notice.md][source: docs/legal/security-and-infrastructure.md][source: docs/legal/subprocessor-schedule.md]

## TL;DR

- Roles: Customer acts as controller/business for Customer Data, and Kitchen Toolkit acts as processor/service provider only to provide, secure, support, and improve the hosted service. [source: docs/legal/terms-of-service.md][source: docs/legal/privacy-notice.md]
- Security baseline: admin sessions, device signatures, tenant scoping, encrypted tenant secrets, masked exports, and bounded retention/deletion controls are the current repo-backed controls. [source: docs/legal/security-and-infrastructure.md][source: docs/reference/retention-policy.md]
- Subprocessors and transfers: the current hosted stack is documented in the Subprocessor Schedule, and cross-border/region handling should be paired with the standard transfer addendum when required. [source: docs/legal/subprocessor-schedule.md][source: docs/legal/transfer-addendum-scc.md]

## Standard positions

### 1. Scope and instruction baseline
- Kitchen Toolkit may process Customer Data only to host, secure, support, troubleshoot, export, delete, and otherwise operate the Kitchen Toolkit service requested by the customer, including approved support flows such as `/help` when the customer uses them. [source: docs/legal/terms-of-service.md][source: docs/legal/privacy-notice.md][source: pages/api/support-bot.js]
- Customer instructions are limited to the documented product configuration choices and any additional written instructions accepted through a signed order form, signed DPA packet, or support/legal channel. [source: docs/legal/terms-of-service.md][source: pilot-order-form.md][source: docs/legal/data-processing-requests.md]

### 2. Confidentiality and personnel access
- Kitchen Toolkit personnel or contractors may access Customer Data only on a need-to-know basis for support, security, maintenance, or service-operation purposes, and only through the authenticated/admin flows or provider infrastructure already described in the repo docs. [source: docs/legal/terms-of-service.md][source: docs/legal/security-and-infrastructure.md]

### 3. Security measures
- The baseline technical and organizational measures for this template are the controls described in the Security & Infrastructure Statement, including signed admin sessions, CSRF, tenant scoping, per-device HMAC verification, encrypted tenant credentials, masked env reads, and audit logging for tenant env updates when KV auditing is available. [source: docs/legal/security-and-infrastructure.md][source: pages/api/updateTenantEnv.js]
- Help attachments and support-session data are additionally subject to the documented consent, temporary Upstash-backed caching, and short-lived attachment-image publication behavior disclosed in the Privacy Notice and `/help` UI. [source: pages/help.jsx][source: docs/legal/privacy-notice.md][source: lib/agent/attachmentImageStore.js]

### 4. Subprocessors
- Kitchen Toolkit may use the subprocessors listed in the published Subprocessor Schedule for the feature scopes described there. Customer-configured SMTP, webhook, or KV providers remain under customer control and are only used when the customer enables them. [source: docs/legal/subprocessor-schedule.md][source: pages/admin/settings.js][source: lib/tenant/env.js]

### 5. Incident notice and support
- Security incidents involving KT systems or tenant data are communicated to tenant contacts without undue delay after KT becomes aware, subject to applicable law and law-enforcement constraints. [source: docs/legal/terms-of-service.md][source: docs/legal/incident-response-runbook.md]

### 6. Return, export, and deletion
- Customers can export tenant data through the documented admin flows and can request deletion or shorten retention through the published delete/retention paths. KT does not maintain separate backups of tenant KV data, but Git history and customer-managed provider backups may persist outside KT control. [source: docs/legal/data-export-deletion-policy.md][source: docs/reference/retention-policy.md][source: docs/reference/data-and-privacy.md]

### 7. Audit and assistance model
- The standard audit posture is documentation-first: customer reviews should start with the legal docs, security statement, subprocessor schedule, OSS notice pack, and the documented export/deletion behavior. Any expanded review, questionnaire, or customer-specific audit right should be scoped in the signed contract packet rather than assumed from the public docs alone. [source: docs/legal/security-and-infrastructure.md][source: docs/legal/subprocessor-schedule.md][source: docs/legal/third-party-notices.md][source: docs/legal/data-processing-requests.md]

### 8. Order of precedence
- If a signed DPA based on this template conflicts with the public Terms of Service or Privacy Notice, the signed DPA should control only for the customer-specific privacy terms it expressly addresses. [source: docs/legal/terms-of-service.md][source: docs/legal/privacy-notice.md][source: pilot-order-form.md]

## Annex A — Processing details

| Item | Standard position |
| --- | --- |
| Subject matter | Hosted software for temperature logging, checklists, alerts, builder content, exports, and optional support/help workflows. |
| Duration | For the subscription / pilot / service term plus any documented retention window or deletion-processing period. |
| Nature of processing | Collection, storage, organization, alerting, export, deletion, support, and limited troubleshooting of customer-submitted operational data. |
| Data subjects | Customer personnel, admins, device operators, and customer-designated notification recipients whose information the customer submits to the service. |
| Data categories | Logs, telemetry, device IDs, timestamps, restaurant/tenant identifiers, contact and notification details, tenant profile data, support/help submissions, and related metadata documented in the Privacy Notice. |
| Sensitive data expectation | Customers should not upload payment-card data, identity documents, or other sensitive categories KT does not request. |

[source: docs/legal/privacy-notice.md][source: docs/legal/terms-of-service.md][source: docs/legal/data-export-deletion-policy.md][source: pages/api/support-bot.js]

## Annex B — Security reference

- Use the Security & Infrastructure Statement as Annex B for the current standard technical and organizational measures, together with the incident-response runbook, retention policy, and environment-variable policy where the customer questionnaire needs extra detail. [source: docs/legal/security-and-infrastructure.md][source: docs/legal/incident-response-runbook.md][source: docs/reference/retention-policy.md][source: docs/legal/environment-variables-policy.md]

## Last verified

- Last verified: 2026-03-22 while aligning this template to the current Terms of Service, Privacy Notice, security statement, support/help flow, and export/deletion docs. [source: docs/legal/terms-of-service.md][source: docs/legal/privacy-notice.md][source: docs/legal/security-and-infrastructure.md][source: docs/legal/data-export-deletion-policy.md][source: pages/api/support-bot.js]