How Helm protects what it hears
Helm answers the phone for contractors, so it holds conversations with homeowners: names, addresses, and what is broken in the house. Here is what protects them.
One customer's data cannot reach another
Every record in Helm carries the organization it belongs to, and the database itself refuses to return rows from anyone else's. This is enforced in Postgres with row-level security, not in application code, so it holds for every path into the data — the console, the API, and the storage buckets alike.
Which organization you are is read from your signed session, never from something the browser can ask for.
We test it rather than assert it. Our test suite signs in as two different companies and tries, in both directions, to read, change and delete the other's records, including files in storage. Those tests run in continuous integration on every change, and a failure blocks the change.
Encryption, stated precisely
Everything between you, your customers and Helm travels over TLS. Data stored in our database — messages, transcripts, customer records — sits on encrypted volumes managed by our database provider.
Call audio is different and we would rather be exact about it than reassuring. Recordings are held by the telephony providers that place and receive the calls, under their own encryption at rest. Helm stores a reference to a recording, not the audio itself.
We do not keep call media forever
Call transcripts, voicemail references and recording references are kept for 90 days by default, and the window is set per customer. Once a call passes it, that content is removed from Helm and the removal is written to an audit record.
Deletion is deliberately hard to trigger by accident: it runs in preview mode by default and a real deletion requires an explicit confirmation, because data removed on a wrong setting does not come back.
Who opened a conversation is recorded
When someone opens a conversation in the console, Helm records who they were and when. An attempt to open a record belonging to a different company is refused by the database and recorded as a refusal.
Multi-factor sign-in is available on every account, using an authenticator app or a passkey, and accounts that have it are required to complete it rather than merely offered it. A signed-in person can end every other session on their account.
Helm never sees a card number
Payments are processed by Stripe. Card details go from your customer to Stripe directly; they are never stored by Helm and never pass through our database.
Who else processes your data
Helm Pro runs on a small set of named providers for hosting, telephony, payments and email. They are listed, with what each one does, on our subprocessors page in the privacy notice.
Telling us about a problem
Email security@helmpro.io. We reply within one business day.
Useful things to include: what you did, what happened, and roughly when. If you have found a way to reach another company's data, say so first and we will treat it as the most serious thing in our queue.
We will not pursue anyone who reports a genuine security problem to us in good faith and gives us a reasonable chance to fix it.