Encryption Is The Floor, Not The Headline
"Encrypted" is a yes-or-no answer that quietly hides the questions that actually matter.
Encryption gets talked about as a selling point. It is really table stakes. What separates a serious data posture from a basic one is not whether data is encrypted, but how: which keys protect it, who holds them, and how much is exposed if any single one of them is ever compromised.
Ask whether a platform encrypts your data and the answer is almost always yes. That is good, and it is also close to meaningless on its own, because yes is the answer that is supposed to come back. Encryption is the floor that any system holding operator data should already meet. It is not a feature worth a headline or a reassuring line in a sales deck. It is the price of being allowed in the room at all.
The questions that actually separate a serious posture from a basic one sit one level below that yes. They are not difficult to ask, you do not need to be an engineer, and the answers tell you a great deal about whether a company has thought hard about protecting your data or simply checked a box. It is worth learning to ask them, because "we encrypt your data" is where the real conversation starts, not where it ends.
At Rest, In Transit, And The Difference Between Them
Data moves through a few distinct states, and each one needs its own protection. In transit, as data travels between your browser and the system, encryption is now standard and largely a solved problem. Almost everyone does this, and doing it is unremarkable. At rest, where data sits in the database between uses, is the part more often left thin, because it is less visible and takes more deliberate effort. A serious platform encrypts sensitive data at rest as a matter of course, so that a stolen copy of the raw storage, on its own, reveals nothing useful to whoever holds it.
That much is the genuine baseline, and a platform that cannot clearly say it encrypts your data at rest, not only in transit, has told you something important. But even "encrypted at rest" is not the end of the question. It is the start of the more interesting one, because encryption does not make a problem disappear. It moves the problem somewhere else, and where it moves is the part worth understanding.
The Real Question Is The Keys
Encryption takes the problem of protecting your data and converts it into the problem of protecting the keys that unlock it. The data is now unreadable without the key, which means the key is now the thing that matters. So the questions that actually distinguish a strong design from a weak one are all about keys, and they are plain-language questions.
How many keys are there? Is every business protected by the same single key, or does each one have its own? Who can access those keys, and is that access separated from the data itself, so that reaching one does not automatically hand over the other? And the question that ties it all together: what is the blast radius if a single key is exposed? Does compromising one key unlock one business, or all of them at once?
A strong design uses separate keys for each tenant, keeps the keys physically and logically apart from the data they protect, and is built so that compromising any one key unlocks as little as possible. A weaker design encrypts everything under a single master key and considers the job done. And here is the part worth holding onto: both of those designs can truthfully answer yes to "is the data encrypted." The word covers both. The difference between them, which is enormous, lives entirely in the answers to the questions underneath, the ones the single yes conveniently hides.
Why This Is Not Just A Technical Detail
It would be easy to file all of this under engineering trivia, something for the technical team to worry about. But the shape of a company's key design is really a reflection of how seriously it took the question of protecting you, and that is not a technical matter. It is a question of intent and care, and you can read it without writing a line of code.
A company that gives each customer their own key, separates the keys from the data, and limits the blast radius of any single failure has spent real effort minimizing what goes wrong on its worst day. A company that put everything behind one master key and called it encrypted has done the minimum that lets it use the word. Both clear the floor. Only one of them built anything meaningful on top of it. The encryption itself does not tell you which kind of company you are dealing with. The keys do.
Key Finding
"Is it encrypted?" is a yes-or-no that hides the real questions: which keys, held by whom, kept apart from what, and how much is exposed if one of them ever falls.
What To Ask Instead
None of this requires you to become a security engineer, and you should not let anyone make you feel that asking is above your pay grade. It simply means treating "we encrypt your data" as the opening of the conversation rather than the close of it. The better questions are ones any operator can ask in plain language.
Is my data encrypted at rest, not only while it is moving? Do I have my own key, or do I share one master key with every other customer? If a key were somehow exposed, how much would it reach, just my business, or everyone's? A company that has done this well will answer those questions readily and in straight language, because it is proud of the work and has nothing to hide. A company that gets vague, or retreats into jargon, or acts as though the questions are unreasonable, has told you something too.
Encryption is the floor. Everyone worth considering has cleared it. The question worth carrying into any decision about who holds your data is not whether they encrypt it, but what they were willing to build on top of that floor, and whether they can explain it to you without making you feel foolish for asking. The asking is yours to do, and it is entirely fair.