Your dealership’s data stays in your dealership.

01Infrastructure

The application runs on Vercel. Data, authentication, file storage, and background jobs run on Google Firebase and Google Cloud, in United States regions (us-central1 / us-east1 by default).

• Firestore

  Primary database with multi-region replication, automatic backups, and point-in-time recovery. Paths are tenant-scoped under each dealer.

• Firebase Storage

  Vehicle images and generated documents. Bucket rules restrict access by dealership, membership, and permission — the same boundary as the database.

• Cloud Functions

  Server-side jobs run in isolated, ephemeral containers. No persistent shared state between requests.

• Vercel

  The web application sits on Vercel’s edge network with automatic HTTPS and platform DDoS protection.

Google Cloud’s compliance program includes SOC 1/2/3, ISO 27001, PCI DSS, and FedRAMP High. Those certifications cover Google’s infrastructure, not Dealer OS as a company. Review Google’s posture at cloud.google.com/security/compliance.

02Encryption

Traffic between browsers, dealer websites, and our servers uses TLS 1.2 or TLS 1.3. HTTP Strict Transport Security is set for two years, including subdomains, so there is no plain-HTTP fallback. Certificates are issued and renewed by Vercel and Google.

Data in Firestore and Firebase Storage is encrypted at rest with AES-256. Google manages those keys in Cloud KMS.

Fields that would be damaging if a database dump leaked get a second, application layer of AES-256-GCM before they are written:

• Social Security numbers

  Full SSNs on finance applications live in a server-only collection. They are never returned to the client. Decryption happens only when an authenticated dealer generates the PDF.

• Taxpayer identification numbers

  TINs captured for Form 8300 cash reporting are stored the same way — encrypted, server-only, separate from the payer’s name and address record.

• OAuth tokens

  Gmail refresh tokens are encrypted before storage, never logged, and deleted when the dealer disconnects the integration.

03Isolation and access

Authorization is enforced twice: in Firestore and Storage security rules, and again on every authenticated API route. Admin SDK routes bypass database rules, so they re-check the caller’s dealership and permissions themselves.

Tenant boundary

A user belongs to one dealership. Inventory SFTP credentials are bound to that store as well — a feed file cannot select another tenant. Generated PDFs download through authenticated, dealer-scoped routes and are not stored in a public cache.

Roles and permissions

Inside a store, access is a role (Owner, Manager, Salesperson) plus optional per-user grants and revokes. The resolved set is written to the user record and read by both the API and the security rules, so they cannot drift. Owners hold every permission. Some actions — billing-level changes — cannot be granted to anyone else.

Purchase price, pack, and profit are owner-financial fields. They are hidden from staff who lack those permissions, and the CRM agent is forbidden from reading them.

Dealer OS staff

Engineering and support access to production is restricted, logged, and limited to what is needed to operate the service. No employee has standing read access to a dealer’s customer records without a documented support reason.

04Authentication

• Firebase Authentication with email and password, and Google Sign-In.
• New accounts must confirm their email before they can read or write dealership data.
• Sessions use an HTTP-only, SameSite=Lax cookie (dealer_os_session), marked Secure on HTTPS, valid for 48 hours, and cleared on logout.
• OAuth connect flows carry a short-lived CSRF state token in an HTTP-only cookie.
• Failed sign-in attempts are rate-limited by Firebase Authentication.
• Deactivating a team member removes access immediately, including in the security rules.

05AI and customer data

Some features call Anthropic to generate listing copy, assist with CRM follow-up, extract details from a conversation, or answer questions on a dealer website. Those calls are made on behalf of the dealership that invoked the feature. Prompts are built from that store’s records only.

We do not mix dealers in a shared training set. We do not sell customer lists. We do not use dealer data to train a Dealer OS model. Anthropic processes the prompt as a sub-processor so the feature can run — not so other dealers can benefit from your book.

Public website chat is additionally screened for prompt injection and off-topic abuse before a model is called, and replies are sanitized on the way out. The agent cannot return owner-only financials.

06Application security

• Private API routes require a verified session and are scoped to the caller’s dealership. Unauthenticated requests receive 401.
• Public endpoints (contact forms, microsite leads, website chat) and expensive dealer actions (document generation, VIN decode, SMS) are rate-limited.
• Inbound Stripe, email, and SMS webhooks are signature-verified. Unsigned events are rejected.
• Every response sets Content-Security-Policy frame-ancestors (our domains only), Referrer-Policy, X-Content-Type-Options, HSTS, and a restrictive Permissions-Policy.
• Secrets and third-party API keys live in server environment variables. They are not shipped to the browser.
• Outbound SMS is blocked unless the dealership has a recorded consent basis for that customer.

07Logging and incidents

Sign-in events, token refreshes, and failed logins are recorded by Firebase Authentication. API invocations and errors go to Google Cloud Logging. Customer names are not written to application logs; VINs are allowed.

Deal jackets keep an immutable, server-written audit log of sensitive actions — deal edits, document generation, compliance overrides. Team permission changes and Dealer OS admin actions have their own logs.

If a confirmed breach affects personal information, we notify affected users within 72 hours of becoming aware of it, as required under GDPR Article 33, by email and in-platform notice. That notice will describe what happened, what categories of data were involved, who was affected, the likely consequences, and what we have done or will do.

08Sub-processors

These providers process data on our behalf to run the product. We review them before integration. Their certifications describe their infrastructure — not a Dealer OS audit.

09Responsible disclosure

If you believe you have found a vulnerability, report it privately before any public disclosure so we can investigate and fix it. Do not access or exfiltrate real user data.