An HR system holds more sensitive data than almost anything else you run. Most buyers ask about features and never ask this.
An HR and payroll system holds salaries, government IDs, bank details, addresses and health-related leave records for every person you employ — a concentration of sensitive data unlike anything else a small business runs. Before uploading it, there are eight questions worth asking any vendor. None require technical expertise to ask, and the quality of the answers tells you most of what you need to know.
Worth stating plainly, because it changes the seriousness of the evaluation. A workforce system typically holds, for every employee:
A breach here is materially worse than a leak of your customer list, because it exposes people who did not choose the vendor and cannot mitigate the consequences themselves.
Almost every HR product is multi-tenant: many companies' data lives in one system, separated logically. The question is where that separation is enforced.
| Application-only | Every query includes a company filter written by a developer. One missing filter in one endpoint exposes another company's rows. The safety depends on nobody ever making a mistake. |
|---|---|
| Database-enforced | The database itself refuses to return rows outside the current company — row-level security in Postgres, or equivalent. A missing application filter still returns nothing extra. |
Database-enforced isolation is meaningfully stronger because it fails closed. Ask the question directly; a vendor that cannot answer it clearly is telling you something.
If payroll maths runs in the browser, then the numbers arriving at the server were computed on a machine the user controls. Anything computed client-side can be modified client-side, whatever the interface shows.
Salary calculation should run server-side, in code the user cannot reach, with the browser sending inputs and displaying results. Ask where it runs. This one question separates products built with an adversarial mindset from products built to demo well.
Three levels should be distinct and enforced:
Ask specifically what vendor employees can see. "Our support team can view your workspace to help you" is common and not automatically wrong — but it should be logged, limited and disclosed rather than discovered.
Transport encryption (HTTPS) is table stakes; the interesting question is what happens to particularly sensitive values at rest. Any third-party API keys the product holds on your behalf, for instance, should be stored encrypted rather than in plain text, and should never be displayed back in full in a settings screen — showing only the last few characters is the correct pattern.
Ask: is data encrypted at rest, are secrets encrypted separately from general data, and can any staff member read a stored credential in plain text?
Three separate questions people tend to merge:
Ask for an export of everything — employees, attendance, leave, payroll history, tasks — in a usable format such as CSV. Then actually try it during a trial.
This matters for three reasons: continuity if the vendor disappears, leverage at renewal, and the practical reality that you will occasionally need data in a spreadsheet. A product that makes export difficult is making a statement about how it expects to retain you.
Data location. Ask which country the data is stored in and whether that is configurable. Data localisation expectations vary by sector and jurisdiction, and India's Digital Personal Data Protection framework places obligations on you as the entity determining how employee data is processed — you remain accountable for the processor you chose.
Vendor exit. Ask what happens to your data if you cancel: how long before deletion, what is retained and why, and whether you receive confirmation. "It stays in backups indefinitely" is a real answer some vendors give, and you should know it before you sign rather than after.
None of this is legal advice — if you handle employee data at scale or in a regulated sector, take proper professional advice on your specific obligations. The broader buying checklist is here.
If payroll is the module you are evaluating, the payroll-specific checklist adds the questions about computation and export.
| Strongest isolation model | Enforced in the database (e.g. Postgres row-level security), not only in application code |
|---|---|
| Salary calculation | Must run server-side; anything client-side can be manipulated |
| Role scoping | Employee → own records only · Admin → own company only · Vendor → logged, limited, disclosed |
| Secrets | Encrypted at rest and never displayed in full — last-4 masking is the correct pattern |
| Backups | Regular, with tested restores; an untested backup is a hypothesis |
| Export | Full export in CSV or similar — test it during the trial |
| Vendor exit | Ask for the deletion timeline and what is retained afterwards |
Ask where tenant isolation is enforced, where salary calculations run, how access is scoped by role, what is encrypted at rest, how backups and restores work, whether you can export all your data, where the data is stored geographically, and what happens to it if you cancel. The clarity of the answers is itself informative.
It is the separation between different companies' data in a system that serves many companies. The important distinction is where it is enforced: if only application code filters by company, a single missing filter exposes another company's records. If the database enforces it — for example with row-level security in Postgres — a missing application filter still returns nothing extra, because it fails closed.
Because anything computed in the browser runs on a machine the user controls and can therefore be modified there, regardless of what the interface displays. Salary calculations should run server-side, with the browser sending inputs and displaying results, so the numbers that get saved are the ones the server computed.
No. Access should be scoped so an employee sees only their own attendance, leave, tasks and payslips, a company administrator sees everything for their own company and nothing beyond it, and vendor staff have no routine access at all — with any support access logged, time-bound and disclosed to you.
You should be able to, and you should test it during the trial rather than assuming. A full export of employees, attendance, leave, payroll history and tasks in CSV or a similar usable format protects you against vendor failure, gives you leverage at renewal, and covers the everyday need to work with data in a spreadsheet.
Under India's Digital Personal Data Protection framework, the organisation determining how employee personal data is processed carries obligations regarding its handling — and choosing a vendor does not transfer that accountability. Confirm where your data is stored, what your vendor does with it, and take professional advice on the specific obligations that apply to your business.
Merik is multi-tenant with isolation enforced in Postgres by row-level security, not only in application code — every company gets one workspace, and a query from one company cannot return another's rows. Roles are scoped accordingly: employees see their own work, company admins see their own company, and each role has its own navigation and its own allowed set of views.
All salary maths runs server-side in a secured payroll function rather than in the browser. Where the product holds provider API keys for its optional AI features, they are stored only as encrypted ciphertext and the dashboard displays only the last four characters. That AI layer is itself fail-closed behind four gates — a master switch, a per-feature flag, a per-company grant and a monthly call cap — and everything else works with it switched off. See the feature list, the module breakdown, or how it works.
What to look for before picking a workforce platform.
Where a language model earns its place — and where it must not go.
What you need at 5–200 people, what you are sold instead, and the red flags.