An HR system holds the worst possible things to lose.
Salaries. Bank accounts. PAN and Aadhaar numbers. Home addresses. Medical leave. This page says exactly what we do about that, in the words an engineer would use — because a security page written in marketing language tells you nothing.
Security controls
Encryption for the fields that matter
Transport is TLS, as you would expect. On top of that, the most sensitive columns we store — bank account numbers, PAN, Aadhaar, two-factor secrets — are encrypted in the database with AES-256-GCM before they are written.
Authenticated encryption, so silent tampering is detectable, not just unreadable
The key lives outside the database, so a database dump alone decrypts nothing
Passwords are never encrypted — they are bcrypt hashes, cost 12, upgraded on sign-in
Two-factor sign-in
Any user can turn on a second factor: a code from an authenticator app, or a one-time code sent to their email. The stored authenticator secret is itself encrypted, so it is not sitting in a column waiting to be copied.
TOTP authenticator apps, or emailed one-time codes
Sign-in, password reset and the contact form are all rate limited
A wrong email and a wrong password fail identically, so accounts cannot be enumerated
Access decided on the server
Roles are not a UI preference. Every request is checked against the caller's role and scope before anything is read or written — a hidden button and a blocked API are two different things, and only the second one is a permission.
Role-based access across HR, payroll, IT, finance and manager scopes
Managers see their own reporting line, not the whole directory
Uploaded files — contracts, ID scans, receipts — open through short-lived signed links, never guessable URLs
An audit trail with a "why" column
Sensitive actions are recorded with who did it, what changed from and to, when, from which address, and — where an operator action requires it — the stated reason. Salary edits and payroll approvals are attributable, not inferred.
Old value and new value both retained, so a change can be read as a change
IP address and user agent captured alongside the actor
Readable by your own admins from inside the product — it is your log, not ours
One company cannot see another
Every record carries the company it belongs to, and every query is scoped to the caller's company at the data layer — not filtered afterwards in the interface. There is no cross-company view for a customer account to reach, however the URL is edited.
Tenant scope applied server-side on read and on write
An unrecognised plan or suspended company is refused rather than defaulted open
Regression tests pin the gates, so a permission cannot quietly loosen in a later release
Our own access is fenced too
Our operator console — the thing our support team uses — is a separate, restricted surface. It can be locked to specific IP addresses, its actions are audited like any other, and support access to a customer workspace is recorded rather than ambient.
Operator role gated by IP allowlist in production
Standard hardening on the API: security headers, request rate limits, outbound SSRF guards
An Indian company, billing an Indian entity, under Indian law — ask us where a given deployment is hosted and we will tell you
Being straight with you
What we do not claim.
Quorel Technologies does not hold SOC 2, ISO 27001 or any other third-party security certification today, and we will not imply otherwise with a badge on a page. What is written above is what is built and running — no more.
We also will not tell you encryption makes data unbreakable. What it guarantees is that the plaintext is unrecoverable without the key, and the key is not stored beside the data. That is a real, bounded promise, and we would rather give you one of those than a large vague one.
If your procurement process needs a security questionnaire filled in, a DPA signed, or a call with whoever wrote the access-control layer, ask. You will get an engineer, not a form letter.
Responsible disclosure
Found something? Tell us before you tell anyone else.
Email support@quorel.in with “Security” in the subject line. Include what you found, how to reproduce it, and what you think the impact is.
We will acknowledge you, keep you posted while we fix it, and credit you if you would like to be credited. We will not threaten you for reporting in good faith. In return: please do not access, modify or exfiltrate anyone else's data while testing, and give us a reasonable window to ship a fix before publishing.
