CRMish

Security Overview

Last updated: 2026-05-28 · DRAFT v4 — counsel + security review pending

> Not legal advice. Working draft of CRMish's security posture. Linked from the Data Processing Addendum and used by prospective enterprise customers in their vendor-risk reviews.

1. Our approach

CRMish (operated by JAS Operations LLC dba CRMish) treats security as a product property, not a separate workstream. New features ship with security review. Known issues are tracked and triaged. We don't ship promises we can't keep, and we don't hide gaps.

This page summarizes our current security practices as of the effective date and is updated when material practices change.

2. Application security

2.1 Authentication

  • Passwords are hashed with bcrypt at cost factor 12. We never store plaintext passwords.
  • Sessions are stored in iron-session encrypted cookies with HttpOnly, Secure, and SameSite=Lax flags in production.
  • Session lifetime is rolling (~14 days), refreshed on each authenticated request.
  • Password resets use single-use, time-limited tokens. Reset emails do not include the new password.
  • We do not currently offer multi-factor authentication (planned — see §10).

2.2 Authorization

  • Every authenticated request enforces a user-scope check. Workspace data is never returned cross-account.
  • Role-based access (owner vs. affiliate) is enforced at the server-action layer, not relied on at the UI layer alone.
  • Coach Mode visibility is granted only after explicit acceptance by the affiliate.

2.3 Account abuse protection

  • Cloudflare Turnstile is invoked on sign-up and sign-in to slow down credential-stuffing.
  • Failed login attempts are rate-limited per IP and per account.
  • We do not enumerate accounts: the same response is returned for "wrong password" and "no such account" on the sign-in surface.

2.4 Input handling

  • All form inputs are validated server-side using Zod schemas before any database write.
  • SQL access is parameterized via Drizzle ORM — no string-concatenated queries.
  • HTML rendering uses React's default escaping. Server actions never dangerouslySetInnerHTML user content.

2.5 Webhook ingest hardening

  • The contacts webhook endpoint authenticates via a per-user secret token.
  • Inbound payloads are size-limited (8KB cap on stored payload).
  • Each webhook event is audit-logged regardless of success or failure.

3. Data security

3.1 Encryption in transit

All connections to CRMish use TLS 1.2 or higher. Production traffic is served by Vercel with automatic HTTPS and HSTS.

3.2 Encryption at rest

  • Database storage (Turso libSQL) is encrypted at rest at the provider level.
  • Backups inherit the same encryption.
  • Environment variables and secrets are stored encrypted in Vercel's secrets store.

3.3 Data minimization

  • We collect only what we need for each feature.
  • AI Coaching prompts are scoped to a single prospect's context, not the full account.
  • Webhook payloads are truncated at 8KB before storage.

3.4 Backups and recovery

  • The database provider (Turso) maintains point-in-time backups consistent with its SLA.
  • We do not currently publish a target Recovery Time Objective (RTO) or Recovery Point Objective (RPO). Enterprise customers can request our current operational practice in writing.

4. Infrastructure security

4.1 Hosting

CRMish is hosted on Vercel with primary infrastructure in the United States and edge delivery globally. Vercel maintains its own security certifications (SOC 2 Type II) and complies with the Standard Contractual Clauses for international transfers.

4.2 Database

The primary database is Turso (libSQL), a managed SQLite-compatible service. Customer data lives in a single region under JAS Operations LLC dba CRMish's account. Auth tokens rotate on a documented cadence (currently quarterly; see §10).

4.3 Secrets management

  • Production secrets (database tokens, Stripe keys, VAPID keys, CRON_SECRET, Anthropic API keys) live in Vercel's environment-variable store, not in source code.
  • Internal access to secrets is restricted to authorized personnel. Each access is logged by Vercel.
  • A canonical copy of every secret is mirrored to 1Password under the JAS Operations LLC dba CRMish vault for disaster recovery.

4.4 Network

We do not maintain customer-facing VPN, SSH, or open ports. All access to the Service is via HTTPS. Internal administrative access uses SSO where the provider supports it.

5. Operational security

5.1 Personnel

  • Personnel with production access sign confidentiality agreements.
  • Access is granted on a need-to-know basis and reviewed periodically.
  • Departing personnel have credentials revoked promptly.

5.2 Software development lifecycle

  • All code changes are reviewed before merge to the production branch.
  • Type-checking (tsc --noEmit) is required before every commit.
  • Dependencies are reviewed at intake; we avoid abandoned or low-quality packages.
  • Critical security patches to dependencies are applied within a reasonable timeframe (typically 7 days for high-severity, 30 days for medium).

5.3 Logging and monitoring

  • Standard web-server access logs are retained for up to 30 days for security and debugging.
  • The webhook audit log is retained for up to 12 months.
  • Authentication events (sign-in, password change, password reset) are logged.
  • We do not log full request bodies that contain user content beyond what is needed for debugging.

5.4 Incident response

  • Suspected incidents are investigated promptly. Severity is triaged within 24 hours of detection.
  • Confirmed Personal Data Breaches are notified to affected customers within 72 hours of confirmation (see DPA §9).
  • Post-incident reviews document root cause and corrective actions.

6. Third-party security

We rely on the security practices of our sub-processors. Key sub-processors with their relevant certifications:

| Provider | Relevant certifications | |---|---| | Vercel | SOC 2 Type II | | Stripe | PCI-DSS Level 1, SOC 1, SOC 2 | | Cloudflare | SOC 2 Type II, ISO 27001 | | Resend | SOC 2 in progress at time of writing | | Anthropic | SOC 2 Type II | | Turso | Encryption at rest; SOC 2 in progress at time of writing |

A full list is at /legal/sub-processors.

7. Customer responsibilities

Security is a shared responsibility. You are responsible for:

  • Choosing a strong, unique password.
  • Keeping your account credentials confidential.
  • Promptly removing access for departed team members.
  • Verifying the legitimacy of any communications claiming to be from CRMish.
  • Reviewing AI-generated content before acting on it.
  • Ensuring you have a lawful basis to import third-party data via webhook integrations.

If you suspect your account has been compromised, email security@crmish.io immediately.

8. Responsible disclosure

We welcome reports of security vulnerabilities. If you believe you have found a vulnerability:

  • Email security@crmish.io with details.
  • Do not exploit the vulnerability beyond what is necessary to demonstrate it.
  • Do not disclose the vulnerability publicly until we have had a reasonable opportunity to address it (we target 90 days from confirmation).
  • Do not violate the privacy of others, destroy data, or interrupt our services.

We will:

  • Acknowledge your report within 3 business days.
  • Provide an initial assessment within 10 business days.
  • Keep you informed of progress.
  • Credit you in any public security advisory unless you prefer otherwise.

We do not currently operate a paid bug-bounty program but appreciate good-faith disclosures.

9. Compliance posture

| Framework | Status | |---|---| | GDPR (EU) / UK GDPR | DPA available — see /legal/dpa | | CCPA / CPRA (California) | See Privacy Policy §11.1 and California Privacy Notice | | HIPAA (U.S. healthcare) | Not in scope — CRMish is not a HIPAA-compliant service | | PCI-DSS | We do not store cardholder data. All card processing is offloaded to Stripe, a PCI-DSS Level 1 service provider | | SOC 2 | Not yet certified. Planned within the first 12 months of paid availability | | ISO 27001 | Not yet certified |

10. Roadmap

These items are committed for the next phase and tracked publicly to set honest expectations:

1. Two-factor authentication (TOTP first, WebAuthn after). 2. SSO for enterprise customers (SAML). 3. SOC 2 Type I → Type II certification process. 4. Automated dependency-vulnerability scanning in CI. 5. Quarterly access reviews with documented sign-off. 6. Published RTO / RPO targets with verified disaster-recovery testing. 7. Internal phishing exercises as personnel grows beyond founder + first hires.

11. Changes

We update this page when material practices change. The "Last updated" at the top reflects the latest revision.

12. Contact

| For | Email | |---|---| | Security incidents and vulnerability reports | security@crmish.io | | Vendor-risk reviews and enterprise security questionnaires | security@crmish.io | | Privacy | privacy@crmish.io |

Document version: security-v1 · Last updated 2026-05-28.