# GreetScribe Security Statement **Effective date:** 2026-05-17 **Version:** 1.0 **Operator:** Qevinto Oy This Security Statement describes security practices and technical safeguards used for GreetScribe. GreetScribe is a multi-tenant hospitality chatbot and guest-assistance platform for business customers. --- ## 1. Operator GreetScribe is operated by: **Qevinto Oy** Business ID: 3583823-3 Sarkakatu 3 F23 96460 Rovaniemi Finland Contact: contact@qevinto.com --- ## 2. Scope This Security Statement applies to GreetScribe and related hosted services operated by Qevinto Oy. It covers: - application hosting; - database hosting; - admin access; - customer access; - chatbot widget security; - tenant isolation; - provider integrations; - technical alerting; - backups; - operational security practices. This Security Statement is informational. Specific customer commitments may be defined in the SaaS Customer Terms, Data Protection Addendum, signed customer agreement, order confirmation, or other written agreement. --- ## 3. Hosting and infrastructure GreetScribe’s primary application hosting is currently hosted through UpCloud in Finland. GreetScribe’s database hosting is currently hosted through Supabase in Sweden. GreetScribe may use additional service providers for email, billing, technical alerts, analytics, marketing measurement, LLM processing, and customer-selected integrations. The current service-provider overview is described in the GreetScribe Subprocessor List. --- ## 4. Multi-tenant architecture GreetScribe is designed as a multi-tenant platform. Tenant-specific configuration, guest-assistance flows, provider integrations, and customer data are separated by tenant or customer context. The architecture separates admin/control-plane concerns from customer-facing runtime concerns. This separation is intended to reduce operational risk and prevent accidental mixing of admin-side configuration and runtime-side guest interactions. --- ## 5. Control-plane and runtime separation GreetScribe uses a control-plane model for customer and runtime configuration. The control-plane is used for administration, client setup, runtime selection, AI runtime settings, and future billing or integration metadata. The runtime layer handles guest-facing chatbot execution and customer-facing interaction flows. Control-plane data is intended to be accessed through backend services, not directly through browser-side database access. Service-role credentials are intended to remain server-side only. --- ## 6. Authentication and access control GreetScribe uses authentication and access-control measures for admin and customer-facing systems. Current or intended controls include: - Supabase Auth; - 2FA; - FIDO/passkeys; - admin roles; - access controls; - server-side authorization checks; - customer or tenant membership checks where applicable. Customers are responsible for managing access by their own staff, contractors, admins, and users. Customers must promptly remove access for people who no longer need it. --- ## 7. Secrets and credentials Qevinto Oy does not intend to expose service-role keys or provider secrets in frontend code. Sensitive credentials are intended to remain in trusted server-side contexts. This may include: - Supabase service-role keys; - provider API keys; - LLM provider keys; - internal service tokens; - signing keys; - integration secrets. Customers must not submit passwords, API keys, payment card data, or other secrets through public chat or support channels unless Qevinto Oy has specifically requested a secure transfer method. --- ## 8. Widget and tenant validation GreetScribe uses tenant and widget validation measures to reduce spoofing and cross-tenant access risk. Controls may include: - tenant/domain validation; - origin validation; - signed widget/session tokens; - widget signature validation; - session validation; - replay protection mechanisms; - nonce and timestamp checks; - rate limiting; - CORS controls. If tenant configuration is missing, inactive, or invalid, GreetScribe is designed to fail safely rather than continue booking-related logic. --- ## 9. Data minimization and logging GreetScribe aims to limit personal data processing to what is needed for the service. Operational logging should avoid unnecessary sensitive data. Technical alerting is intended to use sanitized operational context where possible. Make.com and WhatsApp / Meta technical alerts are intended to include: - technical error information; - correlation ID; - operational alert metadata. These alerts are not intended to include: - guest name; - guest email; - guest phone; - guest chat text; - booking/session data. --- ## 10. Transport security GreetScribe uses HTTPS/TLS for service communication where applicable. Customers should access GreetScribe only through secure connections. Customers should not embed or use GreetScribe in a way that weakens transport security. --- ## 11. Rate limiting and abuse controls GreetScribe may apply rate limits, message limits, token limits, usage limits, or similar controls. These controls are used to protect: - service availability; - customer tenants; - provider APIs; - LLM usage; - billing controls; - system reliability; - abuse prevention. Qevinto Oy may restrict, throttle, suspend, or block usage that creates security, availability, provider, cost, or abuse risk. --- ## 12. Provider integration security GreetScribe may integrate with provider systems such as booking engines, accommodation systems, activity systems, payment providers, PMS systems, CRM systems, or customer-owned platforms. Customer-controlled provider integrations remain the customer’s responsibility. Customers are responsible for: - provider account security; - provider API permissions; - provider credentials; - provider terms; - provider user access; - provider-side data handling; - disabling integrations that are no longer needed. Qevinto Oy may help configure integrations, but Qevinto Oy does not control third-party provider systems. --- ## 13. AI and LLM security boundaries GreetScribe may use OpenAI or other LLM providers for chat assistance and recommendations. AI and LLM features are not intended to accept or reject bookings. AI and LLM features are not intended to accept or reject payments. OpenAI is not intended to receive full chat transcripts by default. OpenAI is not intended to receive guest names, guest email addresses, or guest phone numbers by default. Customers must not configure prompts, flows, integrations, or content to send unnecessary personal data or sensitive data to LLM providers. --- ## 14. Backups GreetScribe uses backups for operational resilience. Backup practices may vary by data category, provider, and environment. Backups may be retained for a limited period according to operational, legal, accounting, dispute, security, and retention needs. Customers should maintain their own copies of important Customer Content, provider data, booking terms, and business records outside GreetScribe where appropriate. --- ## 15. Incident handling Qevinto Oy may investigate suspected security incidents affecting GreetScribe. If a confirmed or suspected security incident affects a customer’s GreetScribe use, Qevinto Oy may notify the affected customer using available contact details. Incident handling may include: - investigation; - containment; - mitigation; - service restriction; - credential rotation; - provider coordination; - customer notification; - technical alerting; - preservation of relevant records; - corrective action. Customers must notify Qevinto Oy promptly if they become aware of unauthorized access, credential exposure, provider-account compromise, or misuse involving GreetScribe. --- ## 16. Customer security responsibilities Customers are responsible for: - using strong authentication; - limiting admin access; - removing unnecessary users; - protecting credentials; - securing provider accounts; - configuring integrations responsibly; - keeping Customer Content accurate; - avoiding unnecessary personal data collection; - not collecting sensitive data unless agreed in writing; - reviewing AI-assisted outputs before relying on them; - maintaining their own website and booking-flow security; - maintaining their own guest-facing privacy and cookie notices where required. --- ## 17. Vulnerability reporting Security concerns may be reported to: contact@qevinto.com Reports should include: - description of the issue; - affected page, widget, account, or endpoint if known; - steps to reproduce if safe; - date and time if known; - screenshots or logs where safe to share; - contact details for follow-up. Do not include passwords, API keys, payment card details, private keys, or unnecessary personal data in security reports. Do not conduct security testing without prior written permission from Qevinto Oy. --- ## 18. No public certification claim Qevinto Oy does not claim in this Security Statement that GreetScribe has a specific third-party security certification unless that certification is separately published by Qevinto Oy. This Security Statement does not claim SOC 2, ISO 27001, PCI DSS, or other certification status. --- ## 19. Changes to this Security Statement Qevinto Oy may update this Security Statement when security practices, providers, hosting, integrations, or the Service change. Updated versions may be published on the GreetScribe website. --- ## 20. Contact Questions about this Security Statement may be sent to: **Qevinto Oy** Sarkakatu 3 F23 96460 Rovaniemi Finland contact@qevinto.com