Tamper-evident vs immutable: what an audit-history check can tell you

When HR software talks about its audit trail, two words often appear: immutable and tamper-evident. They are sometimes used as if they meant the same thing. They do not, and the difference matters if you plan to rely on the history when a payroll or employee record is questioned.

Two different promises

Immutable

An immutable record is one that cannot be changed after it is written. That is a strong claim. Making it true usually depends on more than the application: how and where data is stored, who controls that storage, and whether independent controls stop even administrators from altering it. Without that, "immutable" describes an intention rather than a guarantee.

Tamper-evident

A tamper-evident record is one where changes can be detected. It does not claim that alteration is impossible. It claims that if the recorded sequence is altered, a check can show that something no longer matches. It is a smaller promise, and an easier one to state honestly.

A useful comparison is a sealed envelope. The seal does not stop someone opening the envelope. It lets you see that it was opened.

What HRMS provides

HRMS records payroll and employee events, along with the rule versions that applied. In the local source review, the core platform was started with 24 seeded employees and 651 recorded events. That is evidence of local evaluation, not a production customer result.

Alongside those events, HRMS includes a tenant audit-history check. It examines the sequence of recorded events for changes; the review lists it as hash-chain verification. You can run it from the history and review controls and see whether the recorded sequence still matches.

What the check can tell you

• Whether the sequence of recorded events has been altered since it was recorded, as far as the check covers.
• Where to start looking if something does not match.
• That a history exists to investigate, rather than a final figure with no trail behind it.

What the check cannot tell you

• That an entry was correct when it was made. A wrong value entered properly is still a wrong value. The check confirms the sequence, not the judgement behind each step.
• That storage is independently immutable. Detecting change and preventing change are different properties.
• Who really performed an action. A history records the identity the system was given. The current HRMS evaluation uses a demo persona selector, and production authentication remains outstanding. Until real identity and access enforcement are in place, the "who" in any history is a demo persona, not a verified person.
• That your organisation is compliant. Compliance depends on your rules, processes and obligations, not on a single software check.

Why the distinction is worth making

An overstated audit claim can create more risk than it removes. If a team believes its records are certified immutable, it may skip controls it still needs, such as access reviews, backups or a second check on rule changes. A plainly stated tamper-evident check sets the right expectation: it is a tool for investigation that works alongside other controls.

That is why the limit is stated on the same page as the feature. Our broader reasoning is in why we publish our limits.

How a history check fits a real investigation

Consider a hypothetical query: a reviewer notices that an employee's adjustment in an earlier run looks different from what was discussed. A useful investigation asks three questions in order:

1. What does the record say? Review the recorded events for that run and employee.
2. Has the recorded sequence changed? Run the history check.
3. Was the original entry right? This needs people: the maker, the checker and the supporting documents.

The history check answers the second question. It helps the first and third, but does not replace them. Effective-dated rules and maker-checker stages, explained in effective-dated payroll rules, add context about which rule applied and who approved it.

Questions to ask about any audit trail

• Is the history tamper-evident, immutable, or neither? Who verified that, and how?
• What exactly does the check cover, and what sits outside it?
• How is the identity behind each recorded action established?
• Can rule changes, payroll events and employee changes all be reviewed in one history?
• What independent controls would your auditors or advisers still expect?

The trust and availability page sets out what the review established and what needs verifying before real use. The FAQs answer the history question briefly.

The takeaway

Tamper-evident means you can detect change. Immutable means change is prevented, and that needs independent controls to be true. HRMS offers the first, stated plainly. Treat the check as a strong starting point for investigation, not as the end of one.