Cloud data and retention
This page sets out the data boundary for the BioTrack cloud: what leaves the PC, what the cloud accepts, and how long it keeps it. It is for administrators, data protection contacts and anyone reviewing BioTrack before paying for cloud reporting.
A fixed list of fields
Section titled “A fixed list of fields”BioTrack does not upload its database. For each record, the sender builds a new message containing only the fields on a fixed list, and refuses to send a record that does not match it.
| Record type | Fields sent |
|---|---|
| Attendance event | Event identity, the employee’s ID on the terminal, employee name, employee type, event type, time of the scan, time BioTrack received it, terminal name (if known) |
| Daily record | The employee, the business date, status, check-in and check-out, worked minutes, whether late or left early |
| Calendar override | Date, working or non-working day, name, the local ID of the user who made the change |
| Leave | The employee, the leave dates and details, the local ID of the user who entered it |
| Leave revocation | The leave withdrawn, when, the reason, the local ID of the user who withdrew it |
| Attendance correction | The employee, the business date, the reason, the day’s result before and after, the local ID of the user who made it |
| Published rota week | The week, the site time zone, the publication’s revision and time, shift names and times, role names, the people on it (name and terminal ID) and each person’s shifts per day |
| Health report | Collector, terminal and terminal-clock states, counts such as records waiting or refused, the time of the last scan, the app version and the PC’s time zone |
Every record also carries a unique operation ID and the time it was created, so the cloud can recognise repeats. Draft rotas are never sent; unpublishing a week sends an empty replacement.
Corrections never change the original scans. A correction record contains only the day’s result before and after the change.
Never sent
Section titled “Never sent”- Biometric templates, face images or other biometric media
- BioTrack passwords, password hashes and sign-in sessions
- Terminal user names and passwords
- Recovery passphrases and other recovery secrets
- Raw requests from the terminal
- The installation’s private signing key
What the cloud checks
Section titled “What the cloud checks”The cloud does not trust the PC to get this right. Before it stores anything, it:
- checks the request’s signature against the key registered for this installation, and refuses requests with a clock more than five minutes out or a reused one-time value;
- rejects any record with fields it does not expect;
- rejects any record containing field names that suggest passwords, credentials, sessions, biometric data, templates, images or raw event data;
- refuses attendance from a PC whose cloud subscription is not paid.
Each record in a batch is checked on its own. The cloud stores the records it accepts and returns the rest with a reason; the PC keeps those and shows them as Refused by the cloud. See Sync status.
Organisations are kept apart
Section titled “Organisations are kept apart”The PC never tells the cloud which organisation it belongs to. When an administrator approves a link in the portal, the cloud records the organisation and site against the installation’s key. From then on, the cloud decides where each batch belongs from the installation that signed it.
Two organisations whose terminals happen to use the same employee IDs remain separate. In the portal, people see only the organisations they belong to. Alcra staff see metadata only, never employee names, scans or attendance.
Retention
Section titled “Retention”Each organisation’s cloud data is kept for a period chosen when Alcra sets up the organisation: 1, 3, 5 or 7 years. There are no other options. The portal shows it on the organisation’s Overview as Records kept for.
- Automatic deletion. The cloud deletes the organisation’s attendance events, daily records, calendar overrides, leave, corrections, published rota weeks, delivery records and audit history once they are older than the retention period. The job runs every hour and reaches each organisation at least about once a day. Health history is kept for 90 days.
- Deletion counts only. The cloud keeps a record of each deletion run with the number of items removed, but not the removed data itself.
- Late records are refused. If a record’s date or creation time is already outside the retention period, the cloud refuses it. An old backlog or a replayed request cannot bring expired data back.
- Changing retention. Only Alcra can change the period, and only between the same four values, with your organisation’s approval. Reducing it deletes older cloud data at the next run.
Retention in the cloud does not affect the data on the PC. The local database keeps its own history.
When a subscription lapses
Section titled “When a subscription lapses”If a PC’s cloud subscription is not renewed, its attendance in the cloud is deleted 30 days after the subscription ended: attendance events, daily records, corrections, leave, calendar overrides, published rota weeks, employee names, health history and delivery records. The installation, its licence, its subscription, payments and the audit history remain. Administrators get emails before and after. See Licences and billing.
If the subscription is renewed after the deletion, the PC sends its last 90 days again.
Keys and backups
Section titled “Keys and backups”- The private signing key is created on the PC, encrypted with Windows protection, and never shown in the app, sent to the cloud, or included in support bundles or portable backups.
- Portable backups leave out the cloud address, the signing keys and the cloud registration details. See Backup and recovery.