Originally published at ict.vision
Every white label ICT software demo ends the same way. Your logo appears in the corner, your colours load, your domain resolves, and everyone nods. That part took the vendor an afternoon. It tells you nothing about whether one of your resellers can read another one's customer list.
Rebranding and isolation are different products
The confusion is understandable, because vendors sell them as one thing. They aren't. Rebranding is a presentation concern: logo, palette, domain, login page, invoice header. Isolation is an architecture concern, and it decides who carries the loss when something leaks.
A platform can be excellent at the first and hopeless at the second. Plenty are.
The left column is what gets demoed. The right column is what gets litigated.
The four things that actually have to be separate
Ask about these specifically, and ask to be shown rather than told.
Data. Not just "tenants have their own accounts" but: what stops a query written for tenant A returning tenant B's rows? If the answer is "the application adds a filter", ask what happens when a developer forgets. That's not a hypothetical failure mode, it's the common one.
Configuration and policy. Retention periods, consent handling, do-not-call lists and data residency are not global settings in a serious multi-tenant platform. One reseller selling into healthcare and another selling into retail need different answers, and a shared setting means the strictest customer sets everyone's policy or, worse, doesn't.
Workload. If one reseller fires a large campaign, does everybody else's queue slow down? Per-tenant rate limits are boring until the Monday your biggest partner blames you for their missed SLA.
Visibility. Logs, metrics, and your own support desk. When your engineer opens a ticket for reseller A, can they see reseller B's call records? Most platforms fail this one quietly, because admin tooling is built last and scoped loosely.
Separate databases or row-level security
There are two credible answers, and vendors will tell you theirs is obviously correct. Both work. They fail differently, which is the part worth understanding before you sign.
Neither model is wrong. They just put the risk in different places.
A database per tenant gives you the strongest wall. A mistaken query can't cross it, restoring one customer's data doesn't touch anyone else, and "where does our data live" has a simple answer. You pay in operations: every migration runs once per tenant, costs climb with each one, and any report spanning the fleet turns into a project.
Row-level security in one shared database is cheaper and far easier to run. Onboarding a reseller is a row rather than a build. The risk concentrates: one missing policy on one table exposes every tenant simultaneously, and deleting a single customer's data properly takes real care.
For most white label ICT platforms I'd start with row-level security and treat cross-tenant read tests as non-negotiable, then move the customers who contractually demand it onto their own database. What I wouldn't accept is a vendor who can't tell you which model they use.
Five questions that get past the demo
Show me the query that scopes a tenant. Where is that enforced, in the app or the database?
What happens to everyone else when one tenant sends a million messages this afternoon?
Can your support staff see my resellers' data? Prove the scoping.
How do I delete one reseller completely, and how long does it take?
Which settings are global, and which are per tenant? Show me the list.
The answers matter less than whether they arrive quickly. A vendor who has thought about isolation answers these in a minute. One who hasn't will offer to show you the branding again.
Why this lands on you, not the vendor
We've written before about how white label vendors inherit their resellers' mistakes. The reverse is also true, and it's the direction that catches resellers out: when a shared platform leaks, your customer's contract is with you. Your name is on the login page. That was the whole point of white labelling, and it cuts both ways.
This is also why the platform's programmability matters as much as its feature list, something we covered in why programmable white-label platforms win. A platform you can't inspect is one you're trusting on faith.
Frequently asked questions
Isn't multi-tenant just a marketing term?
It's used as one, often. Treat it as a claim to be tested rather than a category. The useful question is never "is it multi-tenant" but "what specifically is separated, and enforced where".
Is a database per tenant always safer?
It's a stronger wall against query mistakes, yes. It's also more to run, and an under-maintained per-tenant estate with skipped migrations isn't safer than a well-tested shared one. Safety comes from the discipline around the model as much as the model.
Our vendor says row-level security handles it. Is that enough?
It can be, if the policy is enforced by the database rather than remembered by developers, and if there are tests that actively try to read across tenants. Ask to see those tests. If they don't exist, the control is a convention, not a control.
What about branding, is that not worth anything?
It's worth plenty commercially. It just isn't evidence of isolation, and it's routinely presented as though it were. Buy the branding, verify the separation.
How do I check this without an engineering team?
Ask the five questions above and watch how the vendor responds. You don't need to audit the code to notice whether someone has thought about the problem or is hearing it for the first time.
Your logo on the login page is table stakes and takes an afternoon. What separates your resellers from each other is the thing you're actually buying, so make the vendor show you that part.
Top comments (0)