Radu, IT security reviewer^*

Three shapes, same code and the same container images in every one: our managed cloud (Azure Kubernetes Service, run by us), a cluster dedicated to your organisation alone, or your own infrastructure, self-hosted on Kubernetes. Moving between them is a deployment choice, not a rewrite.

Yes. Every tenant gets its own identity realm (Keycloak) and, per our infrastructure practice, its own separate database. A query cannot cross tenant boundaries by accident, because there is no shared table it could cross. This is true whether you're on our shared cluster or a dedicated one.

Yes: Microsoft Entra ID (Azure AD) through Keycloak's OIDC federation, or an on-premises Active Directory through LDAP, with optional Kerberos for a passwordless internal login. Your staff sign in with the credentials they already have; you keep control of the account lifecycle.

New starters, yes: a scheduled job reads your Active Directory over LDAP and creates or updates the matching employee record automatically. Leavers, no, not yet: the sync creates and updates, it does not deactivate someone who has left your directory. Removing an ex-employee's access is still a manual step today.

Permissions are scoped on a six-level ladder, from your own record up to the whole organisation, applied independently to read and write, for every one of 17 securable areas, down to individual business actions such as approve a swap versus delete a leave request. Write access can never exceed read access for the same role.

In the data. A user's accessible units and employees are injected directly into the underlying database query. A manager scoped to their own unit does not just have a greyed-out menu for other units; the query for other units' records structurally excludes them.

Yes, AES-encrypted at the point of storage. Confidential personal fields, fiscal numbers, ID and passport numbers, are served only through separately-gated, write-privileged endpoints, not through the general employee list a wider set of roles can already read.

Yes: a field-level, before-and-after log of who changed what and when, kept indefinitely per tenant with no automatic purge. Coverage is real and actively expanding aggregate by aggregate rather than complete on day one; treat it as comprehensive and growing, not as a claim that every possible change type is logged today.

No. Every internal service-to-service call re-checks the original end user's real permissions; there is no internal call that bypasses authorisation because it came from inside the network rather than from a browser.

Yes. SkyRoster has undergone third-party security testing, and every finding was remediated and is now covered by an automated regression test that fails the build if the same gap reopens.

When an engagement ends we can deprovision your tenant: its identity realm removed, its database dropped, its stored secrets revoked. It is a documented step in how we retire a tenant, not an afterthought we improvise on request.