Security
A payroll system holds the most sensitive data a company has.
Salaries, bank details, passport numbers, medical leave. This page describes what Nova HRM actually enforces, in enough detail that your own security people can ask us a hard question about it.
Each company's data is separated at the database level
Every business table carries the company it belongs to, and that scoping is applied automatically on every query rather than remembered by each developer. It is enforced by an architecture test that fails the build if a new table is added without it, so the guarantee does not weaken as the product grows.
Permissions are per module and per action
Access is granted over a module and one of eight actions — view, create, edit, delete, approve, export, print, configure. A payroll officer who can build a salary structure is not thereby able to approve a loan, because those are different modules with different grants.
Self-service does not mean access to everybody's record
An employee's own record is resolved from their login, not from an identifier in the request, so there is nothing to tamper with. The self-service role holds no permissions at all — an employee sees their own record because it is theirs, not because they were granted the staff directory.
The audit trail cannot be edited
Changes are recorded append-only: audit rows reject update and delete at the model, so the log cannot be tidied up after the fact. Posted financial records are immutable too — a correction is a reversal or an adjustment, never an in-place edit.
Sensitive fields stay out of the audit log
Passport numbers, bank details and similar fields are explicitly excluded from auditing, so the log does not quietly become a second, less-protected copy of the data it is meant to watch over. Telephone numbers and account identifiers are masked by default in the interface, and revealing one is itself a permissioned act.
Approvals have a real authority model
Who may sign an approval is decided in one place, so the policy and the workflow engine cannot drift apart. Configuring a route cannot hand somebody an authority the permission system withheld.
In transit and at rest
Traffic between a browser and the application is served over HTTPS. Passwords are never stored in a recoverable form — they are hashed with a modern, deliberately slow algorithm, so a stolen database does not yield a usable password list.
Where a deployment requires it, each customer can be given a physically separate database rather than a shared one. The scoping described above applies either way; the separate database is an additional boundary, not a replacement for the first.
Who at our end can see your data
Access by our staff is limited to what a support request actually requires, and is granted for that purpose rather than standing open. We do not browse customer data, and we do not use it to train anything.
Your company controls its own users, roles and permissions. We do not change them except on your instruction, or where we must to deliver support you have asked for.
Backups and continuity
Backups are taken on a schedule and restores are tested — an untested backup is a hypothesis rather than a safeguard. The retention period, the recovery objectives and any service level that applies to them are set in your agreement, because they differ by deployment, and we would rather put them in a contract than assert them on a web page.
Reporting a vulnerability
If you believe you have found a security issue, email business@stcc-bs.com with enough detail to reproduce it. Please give us a reasonable opportunity to fix it before publishing.
We will not pursue a researcher who reports a genuine finding in good faith, who does not access or modify data that is not theirs, and who does not degrade the service for anyone else.
What we do not claim
We do not claim a certification we do not hold. If your procurement process needs a specific standard, ask us and we will tell you plainly where we stand rather than gesture at a badge.
No system is perfectly secure, and the most common route into a payroll system is a borrowed password rather than a flaw in the software. The permission model, the audit trail and the approval chain exist so that a compromised account is contained and visible.
See it with your own numbers
We will walk you through a pay run using your salary structures and your chart of accounts.