Designing an HRMS that survives an audit

There is a spreadsheet. It is called something like leave_master_FINAL_v4.xlsx, it lives on one laptop, and it is the actual system of record for how much leave everyone has. The HRMS the company bought two years ago holds a version of the same data that nobody trusts, because the accrual rules in the product do not match the rules in the handbook.

That spreadsheet is the whole problem in one artefact. It has no access control, no audit history, no backup, and one person who understands it. And it exists because the software would not bend to the policy, so the policy went somewhere else.

Access control is a field-level concern

Most HR software gets this wrong in the same way: permissions are attached to screens. A manager can open the employee record page, and the page shows everything on it. But the actual requirement is narrower than any screen — a line manager needs to see their team's leave balance and attendance, and must not see salary, performance history from a previous manager, medical notes or disciplinary records.

That means authorisation belongs on the field, enforced server-side, and it means the API cannot have a single get_employee endpoint that returns the whole row. Retrofitting this is genuinely expensive because it changes every read path, which is why it has to be a design decision rather than a later hardening task.

If your permission model can be described entirely in terms of pages, it is not yet a permission model for HR data.

Reads are auditable events too

For most systems the audit log records changes. For HR data, viewing matters as much as editing — 'who looked at this employee's medical record, and why' is a question that gets asked in real investigations. Log reads of sensitive fields with actor, timestamp and access path. It is cheap at write time and impossible to reconstruct afterwards.

Leave accrual is where the bugs live

Leave looks trivial and is not. Accrual can be monthly, annual, or on completed service. It may be pro-rated on joining and on exit, capped, carried forward with an expiry, encashable up to a limit, and different by grade, location and contract type. Then it interacts with holidays, weekends, half-days, and the question of whether a public holiday inside a leave period is consumed.

Two decisions save you here. First, express the rules as data — a configurable policy the company can change without a deployment — because these rules change more often than any other part of an HR system. Second, never store a balance as a mutable number. Store the ledger of accrual and consumption events and derive the balance. When someone disputes their balance, and they will, you can show them the arithmetic instead of asserting a figure.

What an auditor actually asks for

Labour inspections and internal audits are more predictable than teams expect. The questions repeat, and each maps to something you either built in or will now reconstruct by hand:

• Show me the statutory registers for this period, generated from source records rather than typed.
• Show me that this employee's overtime was calculated at the correct rate, and the approval for it.
• Show me who approved this termination, when, and under what delegated authority.
• Show me the consent basis on which you hold this identity document, and your retention rule for it.
• Show me that access to salary data is restricted, and the log proving it.
• Show me the change history for this employee's grade, with dates and the person who made each change.

None of that is hard if the system was built expecting the questions. All of it is a fortnight of manual reconstruction if it was not.

Retention is a feature, not a policy document

Most organisations keep everything forever, which is the worst option under every data protection regime and also the most expensive after a breach. Data protection law generally requires that personal data is kept only as long as its purpose requires — so a rejected candidate's documents, an ex-employee's medical records and a former contractor's bank details each need a defined life.

Build retention as scheduled, logged, reversible-for-a-window deletion, with a legal-hold flag that suspends it for records under dispute. A policy in a PDF that nobody executes is worse than no policy, because it documents your own non-compliance.

Adoption decides everything else

The best-designed HRMS fails if employees do not use it, because then the data is wrong and every report built on it is fiction. That is a design problem, not a training problem. Applying for leave should take three taps on a phone. Payslips should be one tap from a notification. Managers should approve from the notification without opening the app.

The test is simple: can a warehouse employee with an old Android phone and poor signal check their leave balance in under fifteen seconds? If not, the spreadsheet comes back.