Ringfully is now Inbound CX What’s new
PlatformTrust and privacy
Inbound CX handles your calls to run your phone line and for nothing else. This page is the short version; the policies it links are the long one.
Policy pack
The documents a security review asks for, published in full, with no form to fill in first.
Running your phone line means holding what passes through it: call records and the notes your people type, text messages, contacts, voicemail and, if your company turns recording on, recordings. Recording stays off until it does.
Recording and voicemail audio sits at Twilio rather than on storage of ours, and we keep a reference to it. No AI reads your recordings or your messages, and we do not use your data to train models, ours or anyone else’s.
Traffic is encrypted in transit. Our servers reach the database over TLS and check its certificate against Amazon’s certificate authority, rather than accepting whatever certificate is offered.
Some fields are also encrypted inside the database, with AES-256-GCM: voicemail transcripts, text message bodies, call notes, the street and unit of an emergency address, two-factor secrets and webhook signing secrets. That key and our other secrets are kept in AWS Secrets Manager, and passwords are hashed with bcrypt.
Our servers, database and logs are in AWS US East, in Northern Virginia. Call audio is at Twilio with no region pinned. There is no Canadian or European hosting option.
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. What Law 25 asks of a business
Recordings are deleted after 30 days and voicemail after 90 unless your administrator sets something else, anywhere from 1 day to 3,650 days. Where nobody sets anything, text messages are kept 365 days, and call records and the audit log 2,555 days, about seven years.
A nightly job does the deleting. Recording and voicemail audio is deleted at Twilio, the only place it exists, so it cannot be recovered afterwards. If you leave, ask within thirty days: we give you a copy of your data and then delete it, including from backups on their ordinary cycle.
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. It is one suite among the more than 1,100 automated checks that run on every build.
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 makes it fail outright instead of matching somebody by accident.
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. Anyone on your team can add an authenticator app to their own account, and turning it on or off ends every open session.
You stay signed in through a short-lived pass that renews itself. An old pass used again is treated as theft and ends the whole session. Too many wrong passwords lock the account, not the address they came from, because an address is easy to change.
Your call flow can look a caller up in your own system before deciding where to send them. That goes through a firewall of our own: only over a secure connection, and only to the addresses your company approved. Anything else is refused.
The address is checked at the moment of connecting, not before it, so what was approved is what is actually reached, and every redirect goes through the whole check again.
Recording is off by default, for new companies and every existing one. A company that turns it on 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.
Both sides of a call are recorded separately, and the recording announcement is spoken when a call starts and when somebody presses record. Playing a recording back is a separate permission from making one.
Every organization’s data sits in US East today, whichever company it belongs to.
Choice of data region Coming soon
The companies that handle customer data for us, as the sub-processors page lists them. That page changes before a new one starts, and customers are told directly.
| Sub-processor | Purpose | Region | Since |
|---|---|---|---|
| Twilio | Calls, text messages, numbers and waiting callers | United States, no region pinned | July 2026 |
| Amazon Web Services | Servers, database, secrets, logs and email | US East, Northern Virginia | July 2026 |
| Cloudflare | This website, its DNS and the contact form’s spam check | Global network | August 2026 |
| Counting website visits, after you accept | United States | August 2026 | |
| Namecheap | Our email mailbox | Not yet confirmed | August 2026 |
| Stripe | Subscription billing | United States | Not active |
| Anthropic | The AI assistant step | United States | Not active |
| Sentry | Error reporting | United States | Not active |
“Since” is the month each one started handling data for us, from our own records. The three marked Not active are in the code and receive nothing.
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.
Traffic is encrypted in transit, and passwords are hashed with bcrypt rather than kept in any form we could read back. Voicemail transcripts, text message bodies and call notes are also encrypted inside the database. 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.
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.
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.
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.
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.