Your people’s data, treated like it matters
Payroll holds the most sensitive data a company keeps. These are the controls that protect it.
Encryption at rest & in transit
Sensitive identifiers — PAN, bank details and similar fields — are encrypted at rest with field-level encryption. Traffic to the application is served over TLS, and secrets are never shipped to the browser.
Role-based access control
A base RBAC model with granular custom roles layered on top means people see only what their role allows. Approval workflows and delegation are configurable per company.
Verified tenant isolation
Every query is scoped to your company, backed by Postgres row-level security. Cross-tenant access is designed out at the data layer, not policed after the fact.
Append-only audit trail
Who changed what, when, and from which IP — recorded to an immutable, append-only log across every module, so activity can be reconstructed for accountability.
Authentication by Comsky Identity
Sign-in is delegated to central Comsky Identity (account.comsky.ai) — MFA-ready and session-managed. Comsky HRMS stores no password of its own.
Backups & recovery
Your data is backed up regularly so it can be restored in the event of an incident, and recovery procedures are part of how the service is operated.
Built around the sensitivity of payroll data
- ✓Data handling designed into the product rather than added as an afterthought
- ✓Support for data-principal rights — access, correction and erasure workflows
- ✓Purpose-scoped access to personal data, with an audit trail for accountability
- ✓Clear separation between your company’s data and every other tenant’s
Residency and access
- ✓India data residency — your company and employee data is hosted in India
- ✓Least-privilege access — administrative access to systems is limited and controlled on a need-to-know basis
- ✓Scoped API access — the public REST API uses scoped keys, and outbound webhooks are signed, so integrations get only what they need
- ✓Reproducible runs — payroll runs are immutable and idempotent, so a historical result can always be reproduced for verification
Sub-processors
Who else touches your data, and why.
Questions from your security team?
Ask them. We would rather answer in writing than have you take a marketing page's word for it.