Security

Access control, described plainly

Q: Can one client see another client's data?

No. Records are scoped to your organisation at the data layer rather than filtered in the interface, and access inside your organisation is further controlled by role and data scope.

Q: Can a manager see salaries outside their team?

Only if their data scope extends there. Scope is applied when the data is fetched, not by hiding a button, which is the difference that matters.

Q: Do you hold security certifications?

We are not going to claim a certification we do not hold. If your procurement process requires specific attestations, tell us early and we will give you a direct answer about what we have and what we do not.

Q: What happens if an employee leaves?

Their account can be deactivated immediately, and issued sessions can be revoked so an old device stops working.

Q: Can we see who changed a record?

Yes. Detail pages carry a record history showing the field changed, the previous value, the new value, the person and the time.

Q: Where is our data hosted?

Ask on a technical call and we will walk you through the hosting and file storage setup rather than summarise it in a marketing paragraph.

Most security pages are a wall of logos and adjectives. This one describes what SUVIO actually does, in the same words we would use on a technical call, and stops where our knowledge stops.

Authentication

Logins issue a short lived access token alongside a refresh token held in an httpOnly cookie, which means the long lived credential is not reachable from page scripts. Passwords are stored hashed, never in a readable form.

Each issued refresh token is stored as its own record with an expiry, a revocation flag, and the IP address and user agent it was issued to. That is what makes it possible to revoke a specific device rather than resetting everybody. The web dashboard refreshes silently while you are working and logs you out after a period of inactivity.

Who can see what

Permissions are granted per module and per action, so viewing, creating, editing and deleting are separate grants rather than one blunt access level.

On top of that sits the data scope, which decides whose records a person can reach at all. There are seven: everything, own company, own department, own location, own designation, own subordinates including indirect reports, and own records only. Scope is applied when data is fetched, not by hiding controls in the interface, which is the distinction that decides whether a determined user can get at something they should not.

Audit trail

Detail pages across the system carry a record history. Every change writes the field, the previous value, the new value, the person who made it and when, and changes saved together are grouped so a single edit reads as one event rather than fourteen.

Authentication events, password changes and device pairing are logged separately. In practice this is the feature that ends payroll disputes, because the question stops being who remembers what and becomes what does the record say.

What we are not claiming

We are not listing certifications we do not hold or badges we have not earned. If your procurement process has specific requirements, raise them at the start of the conversation and you will get a direct answer, including where the answer is no.

We would rather lose a deal at the first meeting than at the security review.

Security questions, answered.

Can one client see another client's data?

Can a manager see salaries outside their team?

Do you hold security certifications?

What happens if an employee leaves?

Can we see who changed a record?

Where is our data hosted?

Bring your technical team.

We are happy to walk through the access model in detail rather than summarise it.