The Audit Trail You Will Need Later

The question arrives years after the work: who approved this, when, and what did it say before it was changed. By then the people have moved, the manager has left, and the only thing that can answer is the system's own log.

The deadline pressure in “The Audit Trail You Will Need Later” is a workflow problem before it becomes a people problem. Organisations considering how teams evaluate monitask pricing in relation to monitask pricing can use reminders and current project records to shorten the distance between work and submission, but they should still pay undisputed time and preserve a clear correction route.

Whether it can depends on decisions made at implementation by people optimising for database size, and on a retention setting that has not been looked at since.

For a separate benchmark relevant to “The Audit Trail You Will Need Later”, consult the monday.com work-management resources. Use it to test record quality, approvals, retention, employee rights and exception handling against the real workflow rather than treating a software report as self-explanatory evidence.

What the trail must contain

For each entry: creation with timestamp and author, every modification with timestamp, author and the previous value, submission, approval with timestamp and the natural person responsible, and any subsequent correction with its authorisation.

For the surrounding configuration: the approval routing in force on that date, any delegation active, the rounding rules, the code status. These matter because the answer to "why was this approved by her" is often "because the routing at the time sent it to her", and that fact is not in the entry.

The three common defects

Overwriting. The entry holds its current value and no history. Extremely common, usually a configuration choice rather than a product limitation, and the most damaging of the three.

Attribution to accounts rather than people. The log says a user identifier approved it; three years later nobody knows who held that account, particularly if it was shared or reassigned. The log needs the person, and where it only has the account, a periodic export of the account-to-person mapping is a crude and workable substitute.

Short retention on the audit log specifically. Organisations set a long retention on the records and a short one on the log, because the log is large. The result is records that cannot be explained, which for most purposes is worse than not having them.

Retention, set against the right obligation

The driver is not the timesheet; it is the longest obligation attached to anything the hours fed.

Employment records have a statutory minimum in most jurisdictions. Tax and accounting records have their own, usually longer. Grant conditions commonly require retention for several years after the project closes, which can be a decade from the week in question. Contract limitation periods can be longer still. Construction, defence and pharmaceutical work routinely carry the longest.

Take the longest applicable, apply it to the entries and to the log equally, and write down which obligation set it. Without the last part, somebody will shorten it in three years to save storage.

Deletion requests

Where data protection law gives individuals erasure rights, timesheet records are frequently within scope of a request and frequently exempt from it, because the organisation has a legal obligation to retain them and a legitimate interest in defending claims.

The exemption is real and it is not automatic. It has to be assessed and recorded for the particular records, and the parts that are not needed for the retained purpose — free-text narratives containing third-party details, location data captured incidentally — may well have to go even when the hours stay.

Exporting while you can

Systems get replaced. The migration carries the current state of the records and, in a very large proportion of cases, does not carry the audit log, because mapping it is hard and nobody asked for it in the requirements.

Export the log before any migration, in a readable format, and keep it with the migrated data. This is the single most common way organisations lose their ability to explain historical records, and it is entirely preventable by one line in a migration plan.

The test

Pick an approval from three years ago and reconstruct it completely: who submitted it, when they created each entry, what it said originally, who approved it, under what authority, and what changed afterwards.

If you can do that in an afternoon, the trail works. If you cannot, you now know what is missing, and the time to fix it is before somebody external is the one asking.

Who can read it, and who can change it

An audit trail that the administrators of the system can edit is not an audit trail. This is worth checking rather than assuming: in several products the log is a table like any other, and the people who maintain the system have write access to it.

Equally worth deciding is who can read it. The log contains a detailed record of individuals' working patterns and of managers' behaviour, and uncontrolled access to it is both a privacy question and a reason managers will distrust the whole process. Named access, logged, with a stated purpose, is proportionate and takes an afternoon to set up.