Skip to content

Security & trust

Payroll data deserves better than a shared spreadsheet.

Every WorkHarmony customer gets their own isolated database, their own subdomain, and access control that reaches the individual action.

The security overview covers encryption, retention, backup and restore parameters in detail. We send it on request.

Architecture

Separated at the database, not by a query filter.

Most systems keep every customer in shared tables and add a column to tell them apart. One missing filter in one query is then a data breach. WorkHarmony gives each organisation its own database.

How WorkHarmony separates one customer's data from another A browser connects over an encrypted connection to your own subdomain. The connection reaches the WorkHarmony application, which routes each request to one database. Three separate databases are shown side by side, one per customer, with no connection between them: your organisation's database in the middle and two other customers' databases either side. yourcompany.workharmony.app encrypted connection WorkHarmony application Each request is routed to exactly one database Another customerdb_customer_aYour organisationdb_yourcompanyAnother customerdb_customer_b
No shared tables between customers, and therefore no filter that can be forgotten.

One database per customer. No shared tables, and no tenant column to get wrong.

Technical & access controls

What protects an employee record.

The controls a security reviewer asks about, described plainly.

Role-based access

Permissions reach individual actions and views — which pay elements a manager can see, which rosters, which documents.

Two-factor authentication

An authenticator app, SMS or email as a second factor, with recovery codes. It can be required for the accounts that matter most.

Session management

Inactivity timeouts, and the ability to sign an account out everywhere from the console.

Full audit trail

Views, adjustments, approvals and exports are recorded with who did them and when. Finalised payroll periods lock.

Encryption in transit and at rest

Connections are encrypted, and so are the database and its backups. Parameters are in the security overview.

Signed, expiring document links

Contracts, identity documents and payslips are never served from public URLs. Links are signed and expire.

Error monitoring without personal data

Runtime errors are captured for engineering with personal information removed first.

Backups that are restored, not just taken

Backups run continuously and restores are exercised, because a backup nobody has restored is an assumption.

Generated data in demo environments

No live customer record is copied into a sales or test environment. Demo data is generated.

How we operate

The part that is people, not software.

  • Least-privilege support access

    Support staff need time-bounded, customer-granted elevation to look at your data, and that access is logged.

  • Change control

    Changes are reviewed before release and can be rolled back. Database changes are versioned with the code.

  • Separated environments

    Development and testing run on their own infrastructure with generated data, never on live records.

  • Off-boarding

    Access is removed when someone leaves the team, and reviewed periodically for everyone who remains.

Where your data lives, and how it leaves

  • Your organisation runs on its own database, reachable at your own subdomain.
  • You can request a full export of your data at any time, in a standard format.
  • On exit you take a complete export with you — it is not held back as leverage.
  • Hosting region is confirmed in writing before you sign.

Send us the questionnaire.

Most evaluations start with a spreadsheet of security questions. Send yours and we will complete it properly, rather than pointing you at a marketing page.

We answer questionnaires in full, including the questions where the answer is no.