Legal · Security

Security

A restaurant trusts us with thousands of orders a night and a diner trusts us with their card. Here is how we earn both — the controls we run, the standards we meet, and how to report a vulnerability.

Last updated · May 15, 2026

Overview

Hesett operates a payment, ordering, reservation, and loyalty platform live across 18,000+ tables in Colombia. Security is built into every layer — code, infrastructure, processes, and people. This page summarizes the most important controls; if you need a deeper view (a SOC 2 report, a penetration-test summary, a Data Processing Agreement) write to support@hesett.com.

One-line summary: All traffic is TLS 1.3, all card data goes to Stripe and never to us, all stored data is encrypted at rest with AES-256, all employee access is gated by SSO + hardware keys, and every change to production runs through code review + automated tests.

Data in transit

Every connection to a Hesett endpoint — web app, mobile app, partner dashboard, public APIs — uses TLS 1.2 or higher, with TLS 1.3 as the default. We enforce HSTS with a 12-month max-age and submit our root domain to the HSTS preload list. We score A+ on SSL Labs.

Data at rest

  • Databases (Postgres, Firestore) — AES-256 encryption at rest, encryption keys managed by Google Cloud KMS.
  • Object storage (Cloud Storage, Firebase Storage) — AES-256 server-side encryption.
  • Backups — encrypted with separate keys, retained for 30 days, geographically replicated, restore-tested monthly.
  • Mobile devices — sensitive local data (allergen profile, payment-method tokens, session tokens) is stored in the platform's secure enclave (iOS Keychain, Android Keystore).

Payments — PCI

Card data never touches Hesett infrastructure. Every payment is captured by Stripe Elements in the diner's browser or app and sent directly to Stripe, which is certified to PCI-DSS Level 1. Hesett operates as a Stripe Connect platform and qualifies for the Self-Assessment Questionnaire (SAQ) A — the simplest PCI scope — because we do not store, process, or transmit cardholder data.

For cash payments we record only the amount and the timestamp.

Authentication

  • Diners sign in with email + password, Apple, Google, or one-time codes by SMS / email. Passwords are stored with bcrypt at work factor 12.
  • Two-factor authentication is available for all diner accounts and is required for accounts with stored payment methods over a certain spend threshold.
  • Restaurant staff sign in through the partner portal with SSO (Google Workspace, Microsoft Entra) or 2FA-protected accounts.
  • API access uses short-lived signed tokens; we rotate signing keys on a monthly cadence.

Infrastructure

  • Core back-end on Google Cloud Platform (regions: São Paulo and Iowa) — built on managed services so we never touch raw VM root.
  • Cloudflare in front of every public endpoint for DDoS mitigation, WAF, bot management, and rate limiting.
  • Container images built from minimal base images, signed and scanned for CVEs on every build, deployed only after the scan passes.
  • Configuration is fully declarative (Infrastructure as Code) and reviewed like application code.
  • Production deploys require a passing test suite, two-person code review, and a one-click rollback path.

Internal access

  • Employees sign in with Google Workspace SSO and a hardware security key (YubiKey or platform passkey).
  • Access to production data follows the principle of least privilege — most engineers have zero standing access; access is requested just-in-time, time-bound, and audited.
  • All production access is logged and reviewed quarterly.
  • Employees go through a security onboarding within the first week and an annual refresher.

Monitoring

We run continuous monitoring across application, infrastructure, and security layers — error rates, latency, anomalous sign-in patterns, payment-flow integrity, and security events. Alerts route to an on-call rotation 24/7. We also retain audit logs for 12 months.

Incident response

We follow a documented incident-response runbook with defined severities, response times, and decision-makers. In the event of a confirmed personal-data breach, we notify affected users and the relevant data-protection authorities — US state Attorneys General where required (e.g. California, New York), the Colombian SIC, and EU national DPAs — within the deadlines set by each applicable law (72 hours under GDPR and Colombian Law 1581; faster where US state breach-notification statutes require).

We publish post-incident reports for any security-relevant incident that affected user data.

Responsible disclosure

If you believe you have found a security vulnerability in Hesett, please report it to security@hesett.com. We commit to:

  • Acknowledging your report within 48 hours.
  • Triaging and reproducing the issue within 5 business days.
  • Patching critical vulnerabilities within 30 days.
  • Crediting the reporter (with their permission) in our security hall of fame.
  • Not pursuing legal action against good-faith researchers who follow the rules below.

Please do not exploit a vulnerability beyond the proof of concept, access another user's data, or perform denial-of-service attacks. We will be very happy to coordinate with you on testing windows.

Compliance

  • US privacy laws — CCPA/CPRA, Virginia VCDPA, Colorado CPA, and other state laws honored where applicable; Data Subject Request workflow in place.
  • GDPR — DPO appointed, DPA available, Standard Contractual Clauses in place for EEA-to-US transfers.
  • Colombia Law 1581 — registered with the SIC, processor agreements in place, breach-notification protocols documented.
  • PCI-DSS SAQ A via Stripe Connect.
  • SOC 2 Type II — audit in progress; report available under NDA on request.

Contact