Security & trust.

Crumb is a founder-led early-stage platform. We use established hosting, database, authentication and payment providers, and apply technical and organisational controls appropriate to the current scale of the service. This page describes what is in place today. It is not a claim of independent certification and it is not a contractual service level.

Controls will evolve as Crumb grows and as we take on paying customers with more demanding requirements. Enterprise and pilot customers can request a current summary of controls and provider documentation under NDA.

Primary application data — accounts, menus, ingredients, allergen records, translations, workspace configuration — is stored in a managed Postgres database hosted in the European Economic Area. Static assets and the marketing site are delivered by Cloudflare's global edge network.

Certain service providers (for example transactional email delivery, payment processing, and edge/CDN operations) may process limited data outside the EEA. Where this occurs, transfers are intended to rely on Standard Contractual Clauses or an adequacy decision. See our subprocessors list for the current providers and regions.

Customer data is scoped to a workspace and access is intended to be enforced at the database via Row-Level Security policies on customer-data tables, backed by role checks in a dedicateduser_rolestable resolved through a security-definer function.

Coverage is reviewed as new tables and features are added. We do not claim database-level isolation on every table in the schema without qualification; some internal, administrative, or service-metadata tables are protected by application-layer and service-role controls rather than tenant RLS.

Sign-in is email + password with optional Google OAuth, provided by our authentication vendor. Password reset and invitation links are single-use, time-limited, and delivered from a verified sending domain. Anonymous sign-ups are disabled.

Session tokens are held in browser storage as issued by the authentication SDK. Multi-factor authentication is not currently offered as a self-service control; workspace owners are encouraged to use strong, unique passwords stored in a password manager and enable multi-factor on their Google account when using Google sign-in.

All traffic — marketing pages, dashboard, guest menus, printable exports, and webhooks — is served over HTTPS/TLS. Certificates renew automatically at the edge.

Encryption of data at rest is provided by our infrastructure vendors as part of their managed database, storage, and backup services. We do not operate customer-managed keys, and we do not publish specific cipher or key-length claims independently of the providers' own documentation.

Publishing a menu writes a version snapshot and an audit entry with the actor, timestamp, and readiness state. Scheduled publishes run through the same gate as manual publishes. Restaurants can review their audit log from the workspace's settings.

Crumb relies on provider-managed backup and recovery capabilities for the primary database and storage services. We do not currently publish a contractual Recovery Point Objective or Recovery Time Objective, and recovery procedures are reviewed as the service develops. Restoration is performed by the founder using provider tooling.

Administrative and production access is limited to authorised personnel required to operate and support the service. At Crumb's current stage this is the founder, working from a device with full-disk encryption, screen lock, automatic security updates, a password manager and unique credentials per provider. Support agents never see customer passwords or payment card details — payments are processed by Paddle and card data does not touch Crumb's systems.

Dependencies and platform updates are reviewed regularly, with security issues prioritised according to severity and operational risk. We do not currently operate a formal bug-bounty programme.

If you believe you have found a security issue, please contact security@crumb.menu. Please do not include passwords, sensitive restaurant data, or detailed exploit information in an unencrypted initial email, and please do not perform destructive testing, denial-of-service testing, social engineering, or access data belonging to other users. We will acknowledge good-faith reports as soon as practical.

Crumb investigates suspected security incidents and will notify affected customers or supervisory authorities where required by applicable law, including notification of confirmed personal-data breaches to the Irish Data Protection Commission within 72 hours of becoming aware, in line with GDPR Article 33. We do not currently operate a public status page or 24/7 on-call rotation.

• GDPR — Crumb is designed to support GDPR obligations. Controller and processor roles are set out in the DPA and Privacy Notice.
• Food information (EU 1169/2011 and equivalent) — Crumb provides tools for organising, reviewing and publishing menu, ingredient and allergen information. Restaurants remain responsible for verifying ingredients, supplier information, preparation methods, substitutions, cross-contact risks and all information presented to guests. Crumb does not independently test, certify or verify food, ingredients, recipes, suppliers or kitchen procedures.
• PCI DSS — payments are processed by Paddle as merchant of record. Card data does not enter Crumb's systems.
• SOC 2, ISO 27001 — Crumb is not certified against these frameworks. We are happy to share provider certifications under NDA where relevant.

For security questionnaires, DPIA support, countersigned DPAs, or a sub-processor change subscription, write to security@crumb.menu. We aim to reply promptly during Irish business hours but do not currently commit to a contractual response time.