Skip to content

Security

Your data, kept apart from every other customer.

Several businesses’ calls run through the same software and the same database. This page says, in plain words, how yours are kept apart, who inside your company can see what, and what we do not have yet.

One customer cannot reach another’s recordsOver 1,100 automated checks, one suite just for that35 things a person may do, in 7 groups

Kept apart

Several companies’ calls sit in the same database, and every record carries the company it belongs to. Which company you are comes from your signed-in session, never from anything a request says, so there is nothing to tamper with.

A suite of automated checks exists only to try one company’s session against every other company’s records, and to prove that all of it fails.

Custom role35 permissions
Calls10
Contacts2
Messaging2
Voicemail2
People & access4
Organization13
Emergency calling2

Our staff sign in differently from yours

The sessions your people use and the sessions we use to administer customers are signed with two different keys. If a session ever arrived without saying whose it was, that separation is what makes it fail outright instead of matching somebody by accident.

How we get in

The console we administer customers from is on its own address, always asks for a second factor, and has no way to sign up: we create each account by hand. Its session is kept where the page’s own scripts cannot read it, because that console can list every customer and a stolen session there would matter far more than one person’s.

Staying signed in

You stay signed in through a short-lived pass that renews itself. An old pass being used again is treated as theft and ends the whole session, not just that one request. Too many wrong passwords lock the account, not the address they came from, because an address is easy to change.

Anyone can add an authenticator app to their own account, and turning it on or off ends every open session, including the one that made the change.

When your menu looks something up in your system

Your phone menu can look a caller up in your own system before deciding where to send them. That is a risky thing to allow, so it goes through a firewall of our own: only over a secure connection, and only to the addresses you approved. Anything else is refused.

The address is checked at the moment of connecting, not before it, so what we approved is what we actually reach. A redirect goes through the whole check again.

Recording

Both sides of a call are recorded separately. The company sets the rule, not each person: always, the person’s choice, or never, plus whether the person on the call may stop one that is running. Playing a recording back is a separate permission from making one.

How it works underneath

Every tenant-scoped table carries a tenant id, every query filters on it, and the id is read from the verified session token rather than from anything the request supplied. The isolation suite runs one tenant’s session against every tenant-scoped router and asserts that all of it fails; it is one suite among the 1,100-plus automated checks that run on every build.

Customer sessions and operator sessions are signed with separate keys because our data layer treats an undefined condition as an omitted one: a validly signed token missing its claims would otherwise match an arbitrary account. The operator key is derived from the customer key by HMAC over a domain string rather than set as a second secret, so there is no deployment without the separation.

The operator console is on its own hostname, requires a time-based one-time code with no way to opt out, has no registration route, and keeps its session in an httpOnly cookie. Customer access tokens are short-lived and refresh tokens rotate; replaying a used refresh token revokes the whole chain, and repeated failed sign-ins lock the account rather than the address.

The HTTP block’s egress firewall is a default-deny allowlist, HTTPS only, and the address check runs inside DNS resolution rather than before it, so the address approved is the address actually connected to. Every redirect re-runs the whole check, since a permitted host answering with a redirect to an internal address is the usual way past this kind of control.

Questions people ask

Where is my data held?

In AWS us-east-1, which is Northern Virginia, in the United States. Not a Canadian region, and there is no Canadian or European hosting option. Call audio sits at Twilio with no region pinned. If you are a Quebec business, sending us personal information is a communication outside Quebec, and Law 25 asks you to assess that before you begin rather than after.

What that means for a Quebec business

Is my data encrypted?

Traffic is encrypted in transit, and passwords are hashed with bcrypt rather than kept in any form we could read back. Recording and voicemail audio is held at Twilio rather than on storage of our own, and we keep a reference to it and its details; the sub-processor list names who receives what rather than leaving you to work it out.

Everyone who touches your data, named

Who at Ringfully can listen to a recording?

Nothing in the console we administer customers from will play one. It lists accounts, their numbers and their settings, and it has no way to sign in as one of your people. Inside your own company, playing a recording back is a permission of its own, separate from the one that makes a recording, and every play and download is written to the administrative log your administrators can read and export.

What happens to my data if I leave?

Ask within thirty days of the end and we give you a copy of your data and then delete it, including from backups on their ordinary cycle; after that window we may delete it without asking again. While you are still with us, deletion already runs on a schedule you set, with thirty days for recordings and ninety for voicemail where nobody has set anything, applied by a nightly job. There is no archive behind any of it, so a shortened window deletes on the next run and cannot be undone.

What do you do if there is a breach?

We tell you without undue delay once we know, with what we have at that moment: what happened, which categories and roughly how many records, the likely consequences, and what we are doing about it. Then we keep you updated as we learn more rather than waiting until the picture is complete. Where a breach creates a real risk of significant harm, the people affected and the relevant regulator are told as well, and we keep a record of incidents whether or not they reach that threshold.

How to report something you have found

What we do not have

No independent security certification, and no federated sign-in. Those two are the real gaps. What used to sit beside them no longer does: administrators can export the event log themselves, retention windows are configurable per class of data and a nightly job enforces them, and a request to export or erase one person’s data runs from the product rather than by hand.

Each of those is on the list. If one of them is what your procurement process will actually stop on, ask and we will tell you where it really is rather than what would be convenient.