Trust · Data protection

Define how operational and staff data is handled.

Review the staff records, qualifications, attendance and payroll inputs held in SkyRoster. Assess access, storage location and retention against your organisation’s data-protection requirements.

The employee record

Understand the information held about each employee.

Keep personal details, contract terms and supporting documents together. The employee record can hold an address, profile picture and documents for personal, managerial, qualification, leave and duty purposes.

The most sensitive fields, a fiscal number, an ID or passport number, a home address, a phone number, are held apart from general viewing. They are returned only through a separately gated endpoint that requires write-level access to the employee's primary unit, not the broader read tier that lets a wider set of roles see general employee and roster information. Viewing your own confidential fields through self-service needs only individual-level access, nothing more.

Documents

Review uploaded documents and encryption coverage.

Documents uploaded since release 4.11.0 are encrypted at storage and decrypted when read. Legacy files from earlier releases may be unencrypted and use a separate read path. Review legacy-file coverage and key management for your deployment.

Downloading a document is not just possession of a file identifier: the request explicitly checks that the document belongs to the employee it claims to, before any content is returned. The full mechanism, including how that check sits alongside the platform's other authorisation layers, is on the security page.

The audit trail

Account for personal data in change history.

For supported changes, see the field, its previous and new values, the person who changed it and the time. Readable names help you follow the history of configuration and staffing records.

History covers supported configuration and staffing changes. It does not record every field or action. Confirm the required record coverage, permitted viewers and export needs during evaluation.

Audit history is retained indefinitely per tenant; nothing is automatically purged. Where it matters most, an administrator investigating why a value is what it is can see that history inline, on the exact screen where the change was made, rather than correlating a separate report against the setting they are looking at.

The Audit & History module covers customer-facing access to the central change log, history on individual records, and search and filters across licensed functionality. It is included in SkyHeavy or available as an add-on to other plans. The written offer confirms record coverage. Internal change recording continues to support platform workflows; this packaging does not change retention, existing contractual entitlements or the published limits of shift-change history.

Retention

Agree retention for each category of data.

The product does not impose one retention period on your data. The audit trail's own default is indefinite retention, described above. Employee records, documents and other operational data are kept for as long as your contract and your own configuration keep them.

If your organisation requires automatic deletion, confirm the supported controls, any implementation work and the agreed procedure for each data category. Include employee records, documents, audit history and backups in that review. Set the specific policy →

Configurable

Data residency

Choose where your data lives.

Because each tenant has its own separate database, and because self-hosting is one of the three deployment options, your data can be kept entirely within an infrastructure and a jurisdiction you choose. See the deployment page for what each of the three shapes actually involves.

No public-cloud dependency is architecturally required for the core application, its database, its identity layer, its cache, or its message queue; all of them are self-hostable. A small number of ancillary services, sending transactional email, or where we run backups on your behalf on the managed-cloud shape, have an external dependency by default, and are themselves configurable per environment rather than hard-wired.

Subject rights

Make employee data requests part of the plan.

Every employee can see their own record through self-service, and correct what self-service allows them to correct. An administrator can export an employee's data, or remove it, through the same staff-management tools used day to day, scoped automatically to what that administrator is permitted to see. When an engagement ends, the standing process is to remove the tenant's identity realm, drop its database, and revoke its stored secrets, as part of tenant decommissioning; see deployment for how tenants are isolated in the first place.

Related security and deployment information

Technical detail

Define data requirements before deployment.

Use a 20-minute discovery call to outline your access, retention and residency requirements. We’ll identify the data-protection questions to resolve during evaluation.

Book a discovery call Send your requirements