Multi-tenant HR software: how to tell your data is actually kept separate

When you put your company into an HRIS, you are handing a vendor some of the most sensitive data your organization holds: salaries, banking details for direct deposit, Social Insurance Numbers, home addresses, performance notes. Almost every modern HR platform runs many customer companies on the same shared systems and the same database. That is normal and it is not a problem in itself. The question a Canadian HR leader should ask is narrower and more important: how does the vendor guarantee that another company on that shared platform can never see your data, and how would they even know if that line were crossed? This is a plain-language guide to asking that question well.

What "multi-tenant" actually means

A multi-tenant application serves many customers, called tenants, from one running copy of the software and usually one shared database. Your employees and another company’s employees can live in the same tables, told apart by an organization identifier on each row. The alternative, giving every customer their own isolated database or server, is expensive and rare at the small and mid-sized end of the market, so the realistic question is not "is it multi-tenant" but "how disciplined is the separation."

The risk in multi-tenancy is simple to state. If a single query somewhere in the code forgets to filter by the organization identifier, it can return, or worse overwrite, another tenant’s data. These are not exotic attacks; they are ordinary programming mistakes, and they are the most common way SaaS platforms leak data between customers. Good vendors design specifically so that a single forgotten filter cannot cause a leak, and they test for it continuously.

The questions to ask a vendor

You do not need to be technical to ask these. You are listening for concrete, specific answers rather than reassurance:

  • How is every request tied to my organization, and what stops a user in one company from reading or changing another company’s records?
  • Do you have automated tests that actively try to reach one company’s data from another company’s account, and do those tests run on every release?
  • For the most sensitive records, banking details and compensation, does each record carry its own organization tag, or does it rely only on a chain of relationships to stay separate?
  • Are sensitive fields like bank account numbers and SINs encrypted, and who can see them in plain text?
  • Is there an audit record of who viewed or changed sensitive data?
  • Where is our data stored, and can it be kept in Canada?

A vendor who answers these directly, including admitting what they have not done yet, is telling you something more trustworthy than one who simply says "your data is secure." Vague confidence is the answer to be wary of.

What strong separation looks like in practice

Separation done well tends to share a few traits. Every read and write is pinned to the signed-in user’s organization, so a user simply has no path to another company’s data, not even to confirm it exists. The most sensitive records carry their own organization tag directly on the row, rather than being reachable only through a chain of relationships, so a single mistaken query cannot cross the boundary. And critically, the vendor runs automated isolation tests that stand up two separate companies and prove one cannot reach the other, on every build, so a regression fails the release instead of shipping. Encryption at rest for banking details and SINs, plus an audit trail of sensitive access, round out the posture.

Why this matters more in Canada

Canadian privacy law gives these questions teeth. Under PIPEDA, and in Quebec under Law 25, an organization is accountable for personal information it transfers to a service provider, and Law 25 in particular raised the bar on breach reporting and on the safeguards expected of anyone handling Quebecers’ personal data. When you choose an HRIS you are not outsourcing that accountability, you are extending it, so the vendor’s separation and safeguards become part of your own compliance story. Asking the questions above is due diligence you can document.

This is general information for evaluating a vendor, not legal advice. Confirm your own obligations under PIPEDA and, if you operate in Quebec, Law 25, against the current guidance from the Office of the Privacy Commissioner of Canada and the Commission d’acces a l’information du Quebec.

Where Workleaf stands

We will be direct, including about what we have not done. Workleaf is multi-tenant. Every read and write is pinned to the signed-in user’s organization, so one company cannot read, change, or confirm the existence of another company’s data. Our most sensitive records, banking details and compensation history, each carry their own organization tag on the row and every read pins directly on it, as defence in depth. Bank account numbers are encrypted at rest and are never shown in plain text except through an explicit, access-logged reveal by an authorized HR user. We run an automated two-company isolation test suite on every build that tries to reach one company’s employees, documents, notes, bank details and compensation from the other and proves it cannot; the build fails if any check regresses.

To be precise about what we do not claim: Workleaf does not yet hold a SOC 2 report, ISO 27001 certification, or a third-party penetration test. Those are on our roadmap, not in hand today, and if your procurement requires them we will tell you plainly rather than imply otherwise. Workleaf is also early-access and pre-launch. We would rather earn trust by being exact than by overstating where we are.

Pricing is simple and public. Basic is $15 CAD per month for up to 10 employees, then $1.50 CAD per additional employee. Advanced is $30 CAD per month for up to 10 employees, then $3 CAD per additional employee. No quotes, no surprises.

Ask us the hard questions

Workleaf is bilingual HR software built for Canadian teams, with data separation we can explain line by line. Take a look at what we are building.

See Workleaf
Back to the blog