Every business tool that is not installed on your own server is multi tenant: many companies on one system. The question that matters is what actually stops one of them seeing another, and most published answers to it are a sentence with no mechanism in it.
Here is ours, with the mechanism, and with the parts it does not cover stated as clearly as the parts it does.
Every row knows which workspace it belongs to
Every business record on this platform carries a workspace identifier. Not most of them. Every one: customers, invoices, employees, files, tasks, notes, log entries.
The filter is applied centrally, not by each screen
This is the part that actually matters, and it is the part that differs between implementations that sound identical when described in a sentence.
The workspace filter is not written out on each query by whoever built that screen. It is applied automatically to every read of every one of those records, before the query reaches the database.
The difference is the difference between a rule and a habit. A rule written out by hand on four hundred queries is a rule somebody eventually forgets on one of them, and that one is a leak that no test will find, because the screen still works perfectly. It looks right, it returns rows, and the rows are wrong in a way only the person they belong to would notice.
Applied centrally, it is one rule. It is either right or wrong, and it is checked.
The workspace is proved on every request
When a request arrives claiming to be for a particular workspace, that claim is validated against the membership record every single time.
It is not taken from the session and it is not trusted because it was true a moment ago. Somebody removed from a workspace stops being able to reach it on their very next request, not at their next sign in and not when a cache expires.
Sensitive fields are encrypted individually
Certain fields are encrypted at rest as individual values, rather than relying on the database being encrypted as a whole.
The distinction is worth spelling out. Whole disk encryption protects a stolen server. It does nothing at all about anything that reads the database legitimately, because to a legitimate reader the data is simply there. Field level encryption is the layer that still applies in that situation.
We are equally clear about what it does not cover, because this is where security claims usually stop being useful. Encryption at rest protects a stolen database and does nothing about a log line, an error message, a search index or a lookup that never needed a key. Those are handled separately, by redaction, and they are handled because they were treated as their own problem rather than assumed to be covered by the encryption.
Everything significant is written down
Creating, changing and deleting significant records writes an audit entry recording who, what and when. It is not a setting and it cannot be turned off from inside a workspace.
Permission changes are included, which is the category people most often wish they had a record of and most often do not.
Your data is yours
You can export it. You can ask for a copy, and you can ask for it to be deleted. There is a form on this site for doing both without needing an account, because the person asking is sometimes not the person who holds the login.
Deletion requests are tracked against a deadline rather than handled when somebody remembers.
What we do not claim
We hold no security certifications, and there are no compliance badges anywhere on this site.
A badge naming an audit that nobody has performed is the same category of thing as a testimonial from a company that is not a customer, and we removed both for the same reason. When that changes we will say so, name the auditor, and give the date.
We also do not claim that any of the above makes a breach impossible. What it does is make the boundary between customers a property of the system rather than a property of somebody remembering, and make the record of what happened complete enough to answer questions afterwards.