TIPSY

Email support@tipsyapp.io with SECURITY in the subject line, and enough detail to reproduce. We aim to acknowledge within two business days and to tell you what we intend to do within five.

Please do not open a public issue, access or modify data that is not yours, or run automated scanning against production. We will not pursue legal action against good-faith research that follows this.

We do not currently run a paid bug bounty.

A venue’s data is keyed to its location throughout. Every tenant boundary is a query scoped by that column, not a filter applied after reading.

Identity. Sign-in is Google, Apple, or email and password (bcrypt-hashed). The accounting-firm portal, the supplier portal and the POS portal are separate host-routed surfaces, each with its own identity and session.

Sign-in hardening. New password sign-ups confirm their email address before they can sign in. Passwords must be at least 8 characters and are checked against a breached-password list without the password leaving Tipsy. Reset links work once, expire after 30 minutes, and sign the account out everywhere. Anyone can sign themselves out of every device. Venue accounts can turn on two-step sign-in with an authenticator app and recovery codes; connecting a bank or bookkeeping ledger needs a passkey, Google/Apple, or a password plus a code.

Roles are per location, never global. A manager at one venue is plain staff at another. Authorisation helpers resolve the caller’s role at the location in the request and refuse otherwise.

Route-level, not page-level. Page gating alone was not enough — the API is reached directly — so people data is filtered by a single shared module that every route applies, rather than each route re-deciding. The rules are unit-tested.

Firm access is granted per client and per function. An accounting firm sees only the venues that invited it, and functions within that are assignable. Locking a period is its own permission.

In transit. HTTPS throughout, with HSTS.

At rest. The database is managed Postgres, encrypted at rest by the provider, with 7 days of point-in-time recovery. POS credentials and other restricted fields are additionally encrypted in the application with AES-256-GCM, so a database copy alone does not yield them.

Files. Uploaded invoices and receipts live in a private blob store. They are served only through authenticated streaming routes; there are no public object URLs.

Browser headers. Content-type sniffing is off, HSTS is set, and framing is restricted per surface — relaxed only on the surfaces a venue deliberately embeds in its own site.

Tipsy’s general ledger is append-only. Nothing is edited or deleted after posting; a correction is a reversing entry that points at the original. A closed month is refused at the posting layer, not hidden in the interface.

This matters beyond accounting. It means financial history cannot be quietly rewritten — by a user, by a support engineer, or by an attacker with application access. Five integrity checks run against the books on demand and are enforced at month-end close, so a ledger that has been written to by anything other than a posting shows up as a failure rather than as a number nobody can source.

Firm-side actions against a client’s books are recorded with actor, action, timestamp and detail, and surfaced in an audit pane. Closing a month with outstanding items requires a written reason, which is stored alongside the lock. Supplier catalog changes are logged per actor. Errors go to our monitoring provider.

Services that store or process customer data on our behalf:

• Vercel — hosting, serverless execution, blob storage
• Neon — managed Postgres; all application data at rest
• Stripe — subscription billing and payouts. Card data is held by Stripe; we store customer and subscription identifiers only
• Anthropic — invoice extraction and the Keller assistant
• Resend — transactional email and inbound invoice capture
• Intuit QuickBooks — accounting sync
• Lightspeed — point-of-sale data
• Plaid — bank connections for reconciliation; balances, transactions and statements. Bank login credentials never reach Tipsy. Statement contents are additionally submitted to Anthropic for extraction
• Google — sign-in; document sync for specific sources; Places and review lookups
• Apple — sign-in
• Sentry — error monitoring
• Zebra — cloud label printing; venue, item and batch data, no personal data

Plaid was added to this list on October 14, 2026, after a compliance review found this page still said the bank feed had not shipped. It had. Zebra was missing entirely. Both are recorded with the date rather than quietly inserted, because this page is only worth reading if its corrections are visible.

Customers are notified of material subprocessor changes before they take effect.

• All changes land through a pre-push gate: type checking, linting, the full test suite (3,400+ tests) and a production build. A failing gate blocks the push.
• Money paths are unit-tested to the cent, including journal-entry balance invariants.
• Dependencies come from the public npm registry with a committed lock file.
• Secrets are held as environment variables in our hosting provider. No secret is committed to the repository.

1. Contain — revoke the credential, disable the route, or roll back the deploy. Stopping the bleeding comes before diagnosis.
2. Assess — what data, whose, over what window. Point-in-time recovery and the append-only ledger are the primary tools for establishing what actually changed.
3. Notify — affected customers are told what happened, what data was involved, and what we are doing, without waiting for the investigation to be complete. Where a breach of personal data is notifiable under applicable law, we notify within the required window.
4. Remediate and write it up — a fix, a regression test, and a written post-incident note.

The named owner above is the escalation point.

We are not SOC 2 certified and do not claim to be. Readiness is a separate, funded workstream, not yet begun.

PCI. Tipsy does not store, process or transmit full card numbers. Card data is handled by Stripe. POS card data is handled by the POS provider.

Privacy. Our Privacy Policy and Terms of Service set out data handling, roles and retention. Firm users accept terms explicitly before reaching client data.

Data subject requests. Any user can request a copy of their personal data, or its deletion, from the Account page. Each files a ticket so a person handles it, because deletion touches payroll history that an employer is required by law to retain — those records stay with the employer and are not ours to delete.

In the order we intend to address it:

1. MFA for the accounting-firm and supplier portals, an option for a venue to require it, and SSO for enterprise tenants
2. A single tenant-wide, tamper-evident audit log
3. External security review and remediation sprint
4. Backfill of legacy plaintext POS credentials
5. Automated dependency-vulnerability gating
6. Break-glass approval for platform-administrator tenant access
7. SOC 2 readiness

This list is deliberately public. A customer deciding whether to trust Tipsy is better served by an accurate account of what is missing than by a claim that nothing is.