Trust at Squish

Squish is a multi-service platform. The customer-facing site (squish.co) and the internal CRM (work.squish.co) run on Cloudflare Workers / Pages. Five Node.js backends — squish-backend, squish-crm-backend, squish-provisioning, squish-email, and squish-hosting — run on Railway in the US-East region. Customer records live in Salesforce; transactional state, audit logs, and provisioning metadata live in Google Firestore (US region). Payment data is held by Stripe — Squish is out-of-PCI-scope by design.

Domain registration is brokered through NameSilo. Shared web hosting runs on Plesk nodes hosted on DigitalOcean droplets; Managed Cloud VPS defaults to CyberPanel on its own droplet. Hosted sites are fronted by Bunny's CDN and WAF. Microsoft 365 licensing is brokered through Pax8 (CSP).

• In transit: TLS 1.3 (TLS 1.2 minimum) end-to-end via Cloudflare. HSTS enforced on every customer-facing domain.
• At rest: Firestore default encryption (AES-256), Salesforce platform encryption, Stripe handles all card data with PCI DSS Level 1 controls.
• Secrets: All API keys, service-account credentials, and database connection strings live in Railway environment variables and Cloudflare secret bindings — never committed to source.
• Backups: Firestore point-in-time recovery (7-day window). Salesforce customer records live on the Salesforce platform with its built-in replication and disaster recovery.

• Customer authentication: Firebase Auth (email + password, plus optional OAuth providers). Short-lived JWTs (1-hour TTL).
• Staff authentication: Cloudflare Access in front of every internal surface. SSO + MFA enforced. Session tokens scoped per app.
• Service-to-service: shared internal API key + per-route role gates (admin / support / sales).
• Impersonation: every staff "act as customer" session is logged with reason, end-to-end actions, and start/stop timestamps. Destructive actions (payment-method changes, registrar transfers) are blocked during impersonation by an explicit denylist.

Every privileged action lands in one of these append-only Firestore collections:

• security_events — auth failures, RBAC denials, IDOR attempts, rate-limit trips
• impersonation_sessions — staff-as-customer sessions with per-action sub-collection
• billing_actions — refund issuance, role-cap reasons, second-approver chains
• email_log — every outbound email with kind, suppression reason, send status
• webhook_events — Stripe / NameSilo / Pax8 webhook idempotency leases
• cron_runs — heartbeat for every scheduled job (so missing runs are visible)

Security controls aren't only described in this page — load-bearing ones are asserted in code so that the next deploy can't silently weaken them.

• CI gate on response security headers: every PR runs a vitest smoke test that fails the build if Content-Security-Policy, Cross-Origin-Resource-Policy, anti-clickjacking, or referrer-policy headers drift from their intended values.
• Boot-time third-party permission probe: backend on startup asserts the configured Stripe API key has every scope the dashboard and checkout flows depend on; a missing scope is logged loudly at boot rather than surfacing as silent customer-facing failure.
• Type-driven SOQL helpers reject malformed identifiers at the call site instead of silently coercing to a value that would broaden the query — defense against integration-side SOQL injection.
• Environment-variable readiness manifest: each service declares every variable it consumes, marked required or optional, and an internal endpoint reports which are missing on the running instance — so a missing secret surfaces on a deliberate post-deploy check instead of on the first customer request that needed it.

Operational data is held for short defensible windows; financial records are kept for the 7 years US tax law expects. Customer-deletion requests are honored within 30 days for non-financial data.

Vendors that process customer data on our behalf. Each operates under their own compliance program — links go to their public trust pages.

• Security contact: security@squish.co — staff is alerted in real time.
• Responsible-disclosure policy: /.well-known/security.txt
• Initial response SLA: within one business day.
• Customer notification: within 72 hours of confirmed breach affecting customer data, in line with GDPR Article 33.
• Live system status: squish.co/status

Today: Squish operates a self-attested security program backed by the controls described above. Most of the SOC 2 Type 1 control set (access control, encryption, audit logging, vendor management, change management) is already in place; formal audit is on the roadmap.

SOC 2 Type 1: not yet engaged with an auditor. The control set is largely built; attestation is the next step.

SOC 2 Type 2: begins observation period after Type 1 attestation lands.

For procurement teams: we'll happily complete a security questionnaire (CAIQ-Lite, SIG-Lite, or your own format). Reach out at security@squish.co.

Data Processing Agreement (DPA): our standard DPA, aligned to GDPR Article 28 and including the EU Standard Contractual Clauses, is published at squish.co/dpa and is incorporated into our Terms of Service automatically.