How we protect data, who we share it with, and what we're working on.

All traffic between the platform and your browser is encrypted in transit. Sensitive credentials — QuickBooks® Online OAuth tokens and Restaurant365 delivery credentials — are encrypted at the application layer before they are ever written to the database.

Customer authentication to QuickBooks® Online is fully mediated by Intuit's OAuth 2.0 flow — we never see or store QuickBooks® Online passwords. Internal access to production data is restricted and scoped per organization at the database level.

• OAuth 2.0 with Intuit. Customers authorize access to their QuickBooks® Online data through Intuit's own hosted flow.
• Tenant isolation via Row-Level Security. Every tenant-scoped table enforces RLS keyed to organization_id; membership and role tables are RLS-protected as well.
• Role-based access within each organization. Permissions are assigned per role (e.g. company admin vs. employee), enforced by policy, not just application logic.
• Email-based two-step verification. Required on every login for administrative accounts on organizations with the QuickBooks® Online integration active; available as an opt-in for other accounts.

Customer data is processed and stored on infrastructure located in the United States. Application functions are configured to run primarily in Vercel's Portland, Oregon region (pdx1), alongside the database on AWS us-west-2.

We collect the minimum data needed to deliver QuickBooks® Online documents to Restaurant365. Most of what we process is B2B metadata: company names, invoice lines, payment terms. We deliberately avoid sensitive data categories we don't need.

• Business contact information. Names, emails, phone numbers, and business addresses of customer contacts.
• Invoice and credit memo metadata. Vendor names, customer names, line items, amounts, dates, account numbers, and locations.
• OAuth tokens. Encrypted Intuit tokens, used only to access the QuickBooks® Online data each customer has authorized.
• Operational logs. An audit trail of every document processed, for compliance and support purposes.

What we don't collect or store:

• No personal health information (PHI) or HIPAA-regulated data.
• No credit card numbers or cardholder data. All payments are processed by Stripe.
• No banking credentials. Stripe handles payment methods directly.
• No Social Security numbers, driver's license numbers, or other government IDs.
• No consumer or end-user data. Our customers are businesses.

Our managed database provider runs automated daily backups. We have not yet published a specific recovery point/time objective or a formal, tested restore runbook — see the roadmap in section 09 for what's next here.

Our Master Services Agreement contractually commits us to maintain Technology Errors & Omissions and Cyber Liability insurance for the duration of the agreement.

We maintain a documented Incident Response and Breach Notification Protocol, following the NIST SP 800-61 framework. Customers affected by any confirmed security incident will be notified directly within 72 hours of discovery, in line with applicable breach notification laws.

Read our Incident Response documentation for our detection sources, response phases, notification commitments, and recovery objectives. The full internal Protocol is available under confidentiality upon request for security review or vendor risk assessment.

We use a small, deliberate set of subprocessors. Each is listed below with the specific purpose it serves. We do not sell customer data or share it with marketing or advertising platforms.

We welcome security reports from researchers, customers, and the wider community. We do not currently run a paid bug bounty program, but we will publicly credit contributions that help us resolve material issues.