HR Audit Trail — What an Immutable Log Should Cover
If you have ever sat through an internal IT audit or an external compliance review for an HRM, you know the first question: "show me the audit trail for this change". The audit trail is the single most important compliance feature an HRM ships. Here is what an immutable, useful audit trail should cover — and what to look for in a vendor evaluation.
What "immutable" actually means
An audit log is immutable if no application code path can edit or delete past entries. Two layers of enforcement matter:
- Application-level: there is no API to update an audit entry. Inserts only.
- Data-level: the underlying collection is append-only by design — the application has insert permissions but not update or delete permissions on production audit tables.
If the audit log is "we write to a normal table and try not to update it", that is not immutable.
What an HR audit log must capture
Every state change with compliance, payroll or HR-policy implications:
Identity and access
- Every login (success and failure), with IP, device fingerprint, geo.
- Every password change.
- Every role assignment / change / revocation.
- Every permission grant change at the role level.
- Every impersonation / break-glass access by a vendor or admin.
Compensation
- Every salary change (before, after, effective date, approver).
- Every payroll run (run by, runtime, total processed).
- Every payroll adjustment (manual override).
- Every bank-detail change for any employee.
Employment lifecycle
- Every hire.
- Every role / department / manager change.
- Every leave approval / rejection (with approver identity).
- Every warning issued.
- Every termination (with reason, effective date, processed-by).
Attendance
- Every manual attendance adjustment (HR override).
- Every shift assignment change.
- Every penalty rule modification.
Configuration
- Every change to company-level settings.
- Every tax / EOBI / PESSI rate change.
- Every approval workflow change.
- Every integration credential change.
What the log should record per entry
At minimum:
- Actor (user ObjectId).
- Target (entity type + entity ObjectId).
- Action (e.g.
salary.change,leave.approve). - Before-value and after-value (for state changes).
- Timestamp (server-side, not client-supplied).
- Request metadata (IP, device, user agent).
- Optional reason / comment supplied by the actor.
The before/after pair is critical — "salary changed" with no values is useless to an auditor.
What the log should NOT capture
- Bulk reads. Logging every "view employee profile" produces useless noise that buries the meaningful changes. Log access only when policy explicitly requires it (sensitive views, MNPI material, regulated data).
- Auto-generated background-job state. The scheduler running a daily payroll close-out is not "an actor" in the compliance sense. Log the result and policy-relevant changes, not every cron tick.
Retention
The audit log retention should match the longest applicable regulatory window — for Pakistani enterprise buyers, that is usually 6+ years for tax/payroll records, 10+ years for some banking records, and longer for defense. The HRM should support customer-configured retention rather than a fixed window.
How to evaluate this in a vendor
Three questions:
- "For a salary change on this employee six months ago, show me the audit entry — actor, before, after, timestamp."
- "Can a vendor support engineer edit or delete an audit entry? Walk me through the access model."
- "What is the retention model? Can I extend retention beyond your default?"
Where Zaffre HRM stands
Zaffre HRM writes an immutable audit entry on every compliance-material state change: identity, access, compensation, lifecycle, attendance overrides, configuration. The audit collection is append-only. Vendor access to production is opt-in, audited, and tied to a customer-approved support ticket. Retention is configurable, defaulting to 7 years.