Where the Data Lives

Timesheet records describe named people's daily lives. Where those records are processed engages obligations that a general software decision does not.

The deployment options

Multi-tenant hosted. The usual model. Cheapest, updated on the vendor's schedule, least control.

Single-tenant hosted. Your own instance on their infrastructure. More control over upgrade timing, higher price, and the data is still theirs to process.

Self-managed. You run it. Full control, and you inherit patching, availability and backup — which for a system feeding payroll is a real operational commitment.

The model matters less than the answers to the questions below, and organisations frequently choose a model and never ask them.

The questions

Where is data processed, and where does it rest? Named regions, not "the cloud".

Which subprocessors, and where are they?

Does support access production data, and from where? A support team in another jurisdiction reading records is a transfer whatever the hosting region says.

Are backups in the same region?

Is customer data used to improve the product? Common, buried, and a separate purpose requiring its own basis.

Get these in the contract, because the answers change and a sales email is not a commitment.

Transfers

Time records are personal data, and moving them across jurisdictions engages transfer rules.

A European workforce's records processed outside the region needs a transfer mechanism, documented.

Some organisations keep the statutory record in region and transfer only aggregates. This is a clean arrangement and it has to be designed in, not retrofitted.

Ask during evaluation whether regional hosting is available for your region specifically. Availability varies and is sometimes an enterprise tier.

Availability, realistically

Timesheet systems are not continuously critical. An outage on a Tuesday afternoon is an inconvenience.

An outage during period close is not, and that window is predictable.

Ask about maintenance windows relative to your calendar, and get period-close blackout dates written down.

Ask what happens to clock-in terminals during an outage. They should queue locally, and many do not.

Backup and recovery

Whose responsibility, stated. In hosted models customers frequently assume the vendor has it covered and the contract says otherwise.

Recovery point and recovery time, as numbers.

Whether you can restore a single period or only the whole instance, which matters when a bad import corrupts one month.

Whether you can take your own backup, which is the export question in another form.

Test a restore once. A backup nobody has restored is a belief rather than a control.

Test a restore

A backup nobody has restored is a belief rather than a control.

Ask the vendor to demonstrate restoring a single period, not the whole instance.

Time it.

Check what is lost: edits made since the backup, in-flight approvals, integration state.

Do it once during implementation, while there is no pressure, and record the result.

Whose responsibility it is should be in the contract, because in hosted models both sides commonly assume the other has it.

Availability against your calendar

Timesheet systems are not continuously critical, and there is one window where they are.

An outage on a Tuesday afternoon is an inconvenience.

An outage during period close is not, and that window is entirely predictable.

Ask about maintenance windows relative to your calendar, and get period-close blackout dates written down.

Ask what clock-in terminals do during an outage. They should queue locally, and many simply refuse.

Follow data beyond the primary service

Connected applications may create another storage and transfer route. This service connection is a useful prompt for extending the data-location questionnaire.