Security

This system holds what people are paid.

Salaries, bank details, PAN and Aadhaar numbers, attendance evidence and performance records. That is a higher bar than most business software has to clear, and this page says plainly how we clear it — including the parts that are our responsibility and the parts that are yours.

Access is per action, not per role name

Around forty separate permissions. Reading payroll and running it are different ticks, because they are different jobs — which is what lets you give an accountant what they need without giving them the ability to issue pay.

Sensitive identifiers are encrypted at rest

Bank account numbers, PAN and Aadhaar are encrypted in the database, not merely access-controlled. A database dump is not a spreadsheet of everybody's identity documents.

Every tenant is scoped, in the queries themselves

Company scoping is enforced at the query layer and asserted by a test that fails the build if any scope forgets it. One customer's data cannot be reached from another's session even if a lookup is written carelessly.

Two-factor sign-in, and real lockout

A six-digit code by email, valid ten minutes and usable once. Three wrong codes locks the account, and only somebody with the security permission can unlock it. Repeated failed sign-ins are rate-limited at the edge.

Edits leave a trail, or they do not happen

An attendance correction records who changed it, when, why and what it said before — and tells the person affected. A payslip is never edited; it is reissued as a new version beside the original.

Evidence is captured server-side

The IP behind an attendance punch or a policy acknowledgement is read from the request on the server, never from anything the browser claims — because that is exactly the field somebody would want to forge.

The detail

How it is actually built

TransportHTTPS everywhere, HSTS with a one-year max-age, secure and HttpOnly session cookies with SameSite strict.
Passwordsbcrypt, with a complexity requirement and account lockout after repeated failures. We can never read yours.
Encryption at restBank account numbers, PAN and Aadhaar are encrypted at the application layer. The database itself is encrypted at rest by the host.
Access controlAround 40 per-action permissions; roles you define. Enforced in the controller, the policy layer and the query scope — a screen that forgets to declare its permission is refused, not waved through.
Two-factorEmail one-time code, 10-minute validity, single use, three attempts. Optional per person or required company-wide.
AuditAppend-only rows for attendance edits, payslip reissues, asset custody, leave adjustments, policy acknowledgements and role changes.
Rate limitingSign-in, password reset and public forms are throttled by IP; repeat offenders are banned temporarily at the edge.
BackupsAutomated daily, retained 30 days, restore tested. Point-in-time recovery on the primary database.
Data locationHosted in India by default, which is where most of our customers and their statutory obligations are.
Your data leavingEvery list exports to CSV, at any time, with no export fee. It is your data and there is no hostage-taking on the way out.
Third partiesRazorpay for subscription payments, an email provider for delivery, an error tracker, and — only if you switch it on — an AI provider under terms that exclude training.
AIOff by default. When on, names are pseudonymised where a feature needs people at all, and salary, attendance and leave are never sent.
Honestly

What we are not claiming

Security pages that claim everything are the ones worth distrusting. Here is where we actually are.

Are you ISO 27001 or SOC 2 certified?

Not yet. We are a small company and a certification we have not been through is not something we will imply. The controls on this page are real and you are welcome to test them; the audit badge is not there, and we would rather say so than decorate the page with logos.

Do you have a penetration test report?

We run automated static analysis and dependency vulnerability scanning on every change, and the build fails on a new finding. A third-party penetration test is planned rather than done. Ask us and we will tell you exactly where that stands on the day you ask.

Who on your team can see our data?

Support access to a customer account is a specific permission held by named staff, and using it is logged. We do not browse customer data casually, and we will not read your payroll to answer a question you have not asked us about.

What happens to our data if we leave?

Export everything to CSV first — every list in the product does this and there is no charge. Tell us to delete the account and we remove it, including from backups as those age out on the 30-day cycle.

How do we report a vulnerability?

Email us at hello@spyne.app with the detail. We will acknowledge within two working days, keep you updated, and credit you if you would like us to. We will not threaten anybody who reports something in good faith.

Questions we have not answered here?

Ask directly. A real person who has read the code will answer, and if the answer is "not yet" you will get that instead of a brochure.