Safeguards (TOMs & DPAs)

• All traffic between the diner / merchant browser and WineUp is forced over HTTPS / TLS 1.2 or higher with modern cipher suites. HTTP traffic is redirected to HTTPS at the edge.
• Strict-Transport-Security (HSTS) is enforced with a one-year max-age and the includeSubDomains directive.
• Internal communication between application services and the database uses TLS 1.2+.
• JSON Web Tokens issued at login are signed (HS256), short-lived for sensitive operations (5-minute confirmation tokens) and rotated on password reset.

• The primary database (MongoDB Atlas, see §7 below) encrypts all data at rest using AES-256, including backups and snapshots.
• Passwords are never stored in plain text. They are hashed with the bcrypt algorithm (default work factor 12) prior to persistence. The application never logs raw passwords or hashes.
• Stripe payment-method data is tokenised: WineUp stores only the Stripe customer ID and the card metadata necessary for invoicing (last 4, brand, country). Full card numbers and CVV are never transmitted to or stored by WineUp.
• 2FA codes and password-reset tokens are stored hashed (SHA-256) with a short TTL; the plaintext value is delivered to the user only at the moment of issue.

• Merchant accounts are authenticated by email + password or by Emergent-managed Google OAuth. Passwords must contain at least 8 characters.
• Two-factor authentication (2FA) via email is required on every login from a new device and for every sensitive action (account deletion, subscription cancellation). Trusted-device cookies expire after 30 days and can be revoked individually or globally by the merchant.
• Brute-force protection: failed login attempts are rate-limited per email; sensitive-action codes are single-use, expire in 10 minutes and lock after 5 wrong attempts.
• Server-side authorisation is enforced on every API route: data is queried with the caller's tenant scope (restaurant_id) so no cross-tenant read or write is possible, even with knowledge of internal IDs.
• Inside WineUp Labs, production database access is restricted to authorised engineers, follows the principle of least privilege and is logged centrally.

WineUp is multi-tenant at the application layer. Every collection (restaurants, dishes, wines, pairings, tables, sessions, orders, notifications, staff, guest profiles, etc.) is keyed by restaurant_id. Every read and write query is scoped server-side to the caller's active restaurant. Cross-tenant requests return 403 Forbidden and are recorded in the warning log for auditing.

• Application servers run inside an isolated Kubernetes cluster. The cluster only exposes a single HTTPS ingress; all other ports are firewalled.
• Secrets (database credentials, Stripe keys, OpenAI keys, email API keys, JWT signing key) are stored in environment-managed secrets and are never committed to source control.
• Dependencies are scanned for known vulnerabilities; security patches are applied within 7 days of public disclosure for high or critical severity findings.
• Production data is never copied to developer workstations or to non-production environments.

• The MongoDB Atlas backend operates daily snapshots with a 7-day retention window, plus continuous point-in-time backups within a rolling 24-hour window.
• Backups inherit the same AES-256 encryption-at-rest guarantees as the primary database.
• WineUp targets a Recovery Time Objective (RTO) of 24 hours and a Recovery Point Objective (RPO) of 24 hours for catastrophic failure.
• Restores are tested at least once per calendar quarter.

WineUp relies on the following sub-processors to deliver the service. Each sub-processor is bound by a written data processing agreement (DPA) or equivalent contractual safeguards, and is GDPR-compatible.

When a sub-processor is located outside of the European Economic Area (EEA) or the United Kingdom, WineUp relies on the European Commission's Standard Contractual Clauses (SCCs) (module 3 — processor to processor), the UK Addendum where applicable, and on transfer impact assessments performed for each sub-processor. Where a sub-processor offers an EU data residency option, WineUp uses it by default for customers based in the EEA or UK.

• Application logs capture authentication events, billing operations, AI job lifecycle, sensitive-action confirmations and abnormal errors. Logs do not contain raw passwords, full card numbers, OAuth refresh tokens or guest personal data.
• Logs are retained for up to 90 days for security and fraud investigation, then deleted or anonymised.
• Anomalies (repeated failed logins, cross-tenant access attempts, sudden traffic spikes) are alerted to the WineUp on-call engineer.

• Code changes go through peer review prior to production deployment.
• Dependency vulnerabilities are scanned on every build; critical fixes are deployed within 7 days of disclosure.
• Test data sets used in development never contain production personal data.
• Secrets are rotated on offboarding of any engineer with prior access and after any suspected compromise.

• WineUp maintains an internal incident-response runbook covering detection, containment, eradication, recovery and post-mortem.
• For any personal-data breach affecting Restaurant data, WineUp will notify the Restaurant's registered administrator email within 72 hours of becoming aware of the breach, including the nature of the incident, categories and approximate number of records affected, likely consequences and the measures taken or proposed to address it.
• Post-incident reviews are completed within 14 days of containment and lessons are folded back into the runbook.

• Restaurant data is retained while the subscription is active and the Restaurant continues to use the platform.
• On account deletion (Settings → Danger Zone), all linked data — restaurants, dishes, wines, pairings, tables, sessions, dish entries, wine orders, notifications, staff, guest profiles — is cascade-deleted within 30 days.
• Backups containing deleted data are aged out within their retention window (see §6).
• Security logs may be retained up to 90 days post-deletion to investigate fraud or abuse claims raised before deletion.

Restaurants subject to GDPR, UK GDPR or comparable regimes can request a signed Data Processing Addendum from WineUp by emailing wineuptech@gmail.com with subject “DPA request”. Our standard DPA flows down the Standard Contractual Clauses to every sub-processor listed in §7 and references this Safeguards page as the canonical TOM annex.

This Safeguards page is maintained in lock-step with the Privacy Policy. Material changes are notified to subscribed restaurants by email at least 14 days in advance. Continued use of the service after the effective date constitutes acceptance.

Security or privacy questions, breach reports, sub-processor objection notices, DPA requests: wineuptech@gmail.com.