Security

This is the design decision the rest of the page rests on. Every customer gets their own database, and the platform resolves which one from the hostname before a request reaches any application code. Most multi-tenant products put every customer in shared tables and separate them with a customer_id filter — which means one forgotten WHERE clause, anywhere in the codebase, returns somebody else's rows.

Here that class of bug cannot produce that result: a query written against the wrong filter still runs against a single customer's database, because the connection it runs on was chosen by the hostname. Isolation is a property of the connection rather than of the care taken by whoever wrote the query.

In transit: TLS everywhere, with HTTPS enforced by the platform.

At rest: encryption is provided by the managed database and object storage services.

Credentials you give us — API keys for telephony, messaging and other integrations — are encrypted with AES-256-GCM before they are stored, under a key held in the environment and not in the database. A database dump therefore yields no usable key.

Passwords are stored as bcrypt hashes and are never recoverable, by us or by anyone else. One-time links — password resets, invitations, address confirmations — are stored as SHA-256 hashes rather than as the tokens themselves, expire on a schedule, and are refused after a single use.

Access inside a CRM is by role, and roles carry explicit permissions rather than a rank — a read-only analyst sees the reports and no lead list at all. Sessions are bound to the project they were issued for: a session minted on one customer's hostname is refused on another's, and the hostname wins over the session, never the other way round.

On our side, access to production is limited to the people who operate it, granted for a specific reason and not standing by default.

Call recordings and transcripts are sent to our AI provider only for the features you have switched on. Your data is not used to train models — ours or the provider's. A customer who prefers to pay the provider directly can supply their own key, and then their traffic never touches our account at all.

The managed database service takes continuous backups. Retention, restore targets and the last restore test are [BACKUP POLICY — to be confirmed and then stated here with real numbers, because “we take backups” on its own tells a reviewer nothing].

Report anything you find to admin@larscrm.com. We acknowledge within one business day and will keep you informed until it is closed. We do not pursue people who report vulnerabilities to us in good faith.

If a breach affects customer data, affected customers are told within 72 hours, with what we know at that point — see the DPA.

Stated plainly, because a security page that only lists strengths is one a reviewer stops believing.

• No SOC 2 or ISO 27001 certification. We are a small team and have not been through either audit. If your procurement requires one, tell us now rather than at the end of the process.
• No third-party penetration test yet. [PLANNED — date to be confirmed.]
• No single sign-on or SCIM. Sign-in is email and password; two-factor authentication is on the roadmap and not yet shipped.
• No published uptime history. [STATUS PAGE — to be confirmed.]