Pilot compliance brief
This page is for customer security, privacy, and compliance review. The top cards are the meeting version; orange marks roadmap work or certifications KT is not claiming today.
Read these cards out loud for the short version. Each card has an expandable technical note for IT, privacy, legal, or procurement follow-up.
Kitchen Toolkit is asking to run a contained food-service operations pilot. Staff use the PWA to log work, managers use /admin to review records, and optional sensor nodes help monitor fridge/freezer temperature.
The pilot combines the PWA, admin dashboard, tenant-scoped storage, LoRa temperature nodes, a hub, exports, alerts, and restaurant workflow content.
KT collects kitchen operations records: equipment names, device IDs, temperatures, timestamps, corrective actions, alerts, exports, support contacts, and restaurant workflow content.
Operational records may include equipment IDs, device IDs, node snapshots, hub heartbeats, alert state, tenant profile/env records, push subscriptions, CSV exports, and restaurant bundle content.
By default, KT runs on Vercel and stores each tenant's kitchen records in Upstash KV in AWS N. Virginia. Crew devices may keep temporary offline copies, restaurant bundles are Git-backed, and customers can bring their own KV storage for logs/equipment if needed.
Default hosted storage uses Vercel plus Upstash KV, documented as AWS N. Virginia us-east-1 unless a tenant supplies its own storage KV endpoint. Crew devices may cache restaurant bundles, queued offline logs, device IDs/secrets, push metadata, and short-lived cookies. Builder-published restaurant bundles live in Git-backed tenant folders and mirrored precache folders.
The pilot is not for school records, HR files, payroll, finance, payment cards, health records, government IDs, biometrics, camera surveillance, or employee performance monitoring.
KT does not intentionally collect student/FERPA records, HR/payroll records, finance/accounting records, cardholder data, healthcare/PHI records, government IDs, biometric data, camera surveillance data, or named employee performance records for the pilot.
The pilot can run without customer internal Wi-Fi, VPN, AD/LDAP, SSO, student systems, HR/payroll systems, finance systems, payment systems, or healthcare systems.
The preferred pilot setup uses dedicated LTE connectivity and outbound HTTPS/TLS from the hub to KT APIs, with no inbound customer network ports required.
Admin access is password-protected, tenant MFA is available, passwords are hashed, sensitive tenant settings are encrypted or masked, device uploads are signed, old device requests are rejected, and records are tenant-scoped.
Admin sessions use signed cookies, CSRF checks protect admin writes, tenant admin email MFA is available, passwords use PBKDF2 hashes, tenant secrets use AES-256-GCM envelopes, and devices use HMAC signatures, payload hashes, fresh nonces, and tenant/equipment checks.
KT does not claim generic product-level HACCP certification. HACCP certification does not apply to KT software or hardware as standalone products; it applies primarily to the food operator's food-safety program. KT is designed to support the customer's HACCP-style or preventive-control procedures through logs, alerts, exports, sensor checks, and corrective-action records. Final food-safety decisions, corrective actions, equipment maintenance decisions, and regulatory compliance responsibilities remain with the customer.
Post-pilot evidence can support outside review by a food-safety consultant, HACCP specialist, PCQI, or lab if the customer needs additional workflow or sensor-accuracy validation.
Sensor nodes are wall-mounted away from prep areas, food, and food-contact surfaces. They monitor fridge/freezer air temperature; probes are suspended in open air and are not intended to touch food or other surfaces.
The deployment model minimizes food-contact and prep-surface contact, keeps primary electronics outside cold/wet interiors where practical, and treats KT as operational monitoring and recordkeeping aid rather than certified regulatory instrumentation.
KT is not claiming SOC 2, ISO 27001, HACCP certification, commercial hardware certification, or guaranteed food-safety compliance today. The first major software security target is SOC 2, with ISO and hardware certifications later as the product scales.
Recommended sequence: pilot evidence, gap assessment, security questionnaire and policies, external security assessment or penetration test, SOC 2 Type I, SOC 2 Type II after operating evidence, ISO 27001 for larger/international customers, and FCC/ISED/CE or other hardware review before broad commercial hardware sales.
Admins can export records, configure retention, and delete live KT-controlled records. Copies in Git history, email, customer-owned storage, or provider backups may need separate deletion or retention handling.
Product deletion flows target live operational records in tenant-configured/default KV and covered platform KV records. They do not rewrite Git history or erase independent third-party backups, customer-managed KV backups, email copies, logs, or provider archives outside KT control.
KT has a review packet and standard legal templates. Public-sector privacy review, special data-residency promises, provider restrictions, security addenda, or SLA commitments only apply when agreed in writing.
The public packet includes a DPA template, transfer addendum/SCC packet, subprocessor schedule, Terms, Privacy Notice, Security & Infrastructure statement, and Data Export & Deletion policy. KT can support customer-specific privacy review, including FIPPA/Ontario public-sector review if requested, but public pages do not create customer-specific compliance claims, redlines, or service commitments.
KT is separating what exists today from what comes later. The pilot shows whether the controls, evidence, and customer requirements justify funding each next step.
KT has practical pilot safeguards today: admin password protection, tenant MFA, hashed passwords, encrypted or masked tenant secrets, signed device uploads, tenant-scoped records, export/delete/retention controls, and incident/support docs. This is good hygiene, not SOC 2 or full enterprise IAM.
Current controls include admin sessions, CSRF protection, tenant admin email MFA, PBKDF2 password hashes, AES-256-GCM tenant secret envelopes, HMAC-signed device payloads with hashes/nonces, tenant/equipment checks, and documented export/delete/retention limits. KT does not claim SOC 2, ISO 27001, SSO, SCIM, SIEM, or full named-role RBAC today.
The pilot should collect real logs, alerts, corrective actions, exports, sensor checks, support issues, and customer SOP feedback. After that, KT can decide whether outside food-safety review or sensor-accuracy validation is worth funding.
A later review could involve a food-safety consultant, PCQI, HACCP specialist, ISO/IEC 17025-accredited calibration lab, or other qualified reviewer assessing workflow fit, sensor accuracy evidence, alert logic, record integrity, and calibration procedures.
The first major software security certification target is SOC 2 Type I, then SOC 2 Type II after KT has operating evidence over time. ISO 27001 comes later if larger or international customers require it.
SOC 2 Type I would test control design at a point in time. SOC 2 Type II would test whether controls operate over time. Readiness work includes policies, access evidence, change-management records, incident-response evidence, vendor review, monitoring, vulnerability management, and support/process documentation. ISO 27001 later requires a formal ISMS, risk register, asset inventory, vendor controls, and repeatable governance.
KT has admin authentication and tenant MFA today, but it does not claim full enterprise IAM. SSO, SCIM, finer RBAC, and SIEM export are post-pilot additions if an institutional rollout requires them.
Current access control separates crew/PWA workflows from /admin and supports tenant admin email MFA. Future IAM maturity may include SAML/OIDC SSO, least-privilege named roles, SCIM provisioning/deprovisioning, centralized audit events, and SIEM export, but those are not current pilot claims.
Before broad hardware sales, KT should pursue FCC/ISED radio review and CE where applicable, plus UL/CSA/ETL/NSF only if product design or market requires them. WCAG accessibility and privacy reviews mature with larger deployments.
Hardware/radio paths include FCC in the U.S., ISED in Canada, CE where applicable, and product-safety or food-equipment paths such as UL, CSA, ETL, or NSF depending on power, mounting, food-contact, and market scope. WCAG/AODA review, PIPEDA/FIPPA/GDPR boundary work, PCI-DSS boundary confirmation, FERPA boundary review, and HIPAA-capable architecture are scope-triggered paths, not current pilot certifications.
These are roadmap targets, boundary reviews, or customer-triggered paths. KT is not claiming them as completed certifications today.
The short risk position is that KT is a narrow, independent, operational pilot with useful controls today and a clear roadmap for maturity.
Kitchen Toolkit is currently focused on pilot validation. The purpose of the pilot is to demonstrate operational value, reliability, customer fit, and food-safety workflow support before significant investment is made in formal certifications, audits, or large-scale commercialization activities.
The pilot is intended to generate real-world evidence, including:
The goal is to understand what customers actually need and what requirements create the most value before pursuing formal reviews or certifications.
Successful pilot outcomes may support:
Pilot evidence helps determine which certifications, assessments, or product investments are justified by customer demand.
Once pilot results are available, KT may evaluate funding options to support growth, security improvements, hardware validation, certification readiness, and commercialization activities.
Potential funding sources may include:
Funding opportunities are evaluated based on business needs, eligibility requirements, timing, and available evidence from pilot deployments. Funding is not assumed or guaranteed.
Certification and assessment priorities will be driven by customer requirements and pilot findings. Potential future activities may include:
KT does not currently claim HACCP certification, and HACCP-related work is focused on supporting customer food-safety programs rather than pursuing a generic product certification.
KT may evaluate applicable Canadian and Ontario funding programs, commercialization initiatives, tax incentives, and financing options as the business matures.
Examples may include:
Eligibility, intake periods, matching-fund requirements, and allowable expenses vary by program and must be evaluated at the time of application.
Kitchen Toolkit is seeking a limited, low-risk pilot at a single food-service location. KT would provide the hardware, LTE connectivity, software, setup, and support. The pilot would run alongside existing operations for approximately 60-90 days and evaluate temperature monitoring, alerts, recordkeeping, workflow fit, and operational value. No network integration, procurement commitment, or future deployment decision is required. At the end of the pilot, KT and the customer would review the results together and determine whether further evaluation is warranted.
Download the questionnaire, data-handling summary, retention policy, and pilot architecture as a PDF for deeper review.
The key points from these documents are summarized above; these links are for reviewers who want the source policies and templates.