Features
Audit trails
An audit trail is only worth showing anyone if it could not have been edited. Most systems in this category log changes to a table that an administrator can update, which makes the log a record of what somebody was willing to leave there. That is a different artefact, and inspectors know it.
- Quality and compliance
- Clinical engineering
- Executive and finance
What is an append-only audit trail?
Definition
Append-only, hash-chained audit trail
An append-only audit trail is a record of events to which entries can only be added, never modified or removed, where each entry carries a hash of the previous entry so that any alteration to the history breaks the chain and becomes detectable.
The two properties do different jobs. Append-only removes the ordinary ways history changes: no UPDATE, no DELETE, no "correcting" a row. Hash chaining addresses the extraordinary way: someone with database access going around the application entirely. Chained hashes mean tampering is not prevented so much as made evident, which is the achievable goal.
What neither property does is make the entries true. An audit trail records what the system was told to do. It is evidence of process, not of reality, and claiming more than that would be overselling. Its value is narrow and real: it establishes that the record you are looking at now is the record that was written then.
Why most audit logging is not evidence
Because it is written after the fact, by a separate path, into a table that can be changed. Each of those three is enough on its own to make it inadmissible in practice.
The most common architecture is a log written after the business change commits, often by an event handler or a background job. That produces a window: the change succeeded and the log did not, and nothing reconciles them. The window is usually small and always at the worst moment, because the times a system fails to write a log are correlated with the times something interesting was happening.
The second failure is mutability. If the audit table can be updated, then the audit trail is exactly as trustworthy as the least careful person with write access, and its value collapses to that. A log an administrator can tidy is not a control, it is a diary.
The third is scope. An audit trail that covers the application but not the exports, the API, the webhooks or the storage is a boundary with a door in it. The interesting question in an incident is rarely "who clicked the button" and often "who took the data out", and that question needs the same coverage.
How Rydya writes audit
In the same transaction, append-only, hash-chained, enforced at the database rather than by convention.
- 1
Same transaction as the change
The audit event is written in the same database transaction as the change it records. Either both happen or neither does. There is no window in which the change exists and the record of it does not, and no background job whose failure would go unnoticed.
- 2
No update path, no delete path
Enforced at the database, not by the application politely declining. There is no code path that edits an audit event, because the ability to write one would be the vulnerability.
- 3
Hash chained
Each event carries a hash linking it to the history before it. Altering an entry directly in the database breaks the chain, which converts silent tampering into detectable tampering. That is the honest description of what this buys.
- 4
Permission checked on the server first
Every protected action is authorised server side before it happens, so the trail records actions that were actually permitted rather than actions that were merely attempted through a UI that failed to hide a button.
- 5
Scoped like everything else
Audit events carry the organisation id and are protected by row level security like every other tenant record. One tenant cannot read another tenant's history, which is exactly as important as the isolation on the data itself.
How the chain actually works
Each event carries the previous hash, so altering one breaks every link after it.
What this makes possible
Four things that are impossible with a mutable log, and one thing it deliberately does not solve.
Corrections that are amendments, not edits
When something recorded is wrong, the fix is a new audited event that supersedes it, not a quiet change to the old one. Both states remain visible, which is what an inspector actually wants to see: not perfection, but honesty about a correction.
Financial records that hold
Original amounts and currency are immutable. Conversions carry their rate, source and timestamp rather than overwriting the figure they came from, and closed financial records are never edited in place. This is why the money numbers survive a finance review.
A readable audit report
Who did what, when, and to which record, as a view rather than a database export somebody has to interpret. The property that makes it worth reading is that it could not have been curated first.
Real answers in an incident
When something has gone wrong with a device, the question is what happened and in what order. A trail written transactionally answers that. A trail written by a best-effort background job answers it approximately, which is not an answer.
What it does not do
It does not prove the entries were true, only that they are unchanged since they were written. Nobody should claim more than that, and the narrowness is what makes the claim worth anything.
Audit approaches compared
These all get described as "audit logging" on a feature matrix. They are not close to equivalent.
| Approach | Gap between change and record | Can it be edited? | Tampering visible? |
|---|---|---|---|
| Application log file | Whenever the process flushes | Yes, and rotated away | No |
| Audit table, written after commit | A real window, at the worst moments | Usually, by an admin | No |
| Audit table, background job | Seconds to never | Usually | No |
| Append-only, same transaction | None | No path exists | Not yet |
| Append-only, hash-chained, same transaction | None | No path exists | Yes, the chain breaks |
What each audit approach can actually establish
Who asks for this, and when
Security reviewers ask during procurement. Inspectors ask during an audit. Lawyers ask after an incident. All three are asking the same question in different words.
The question is: can this record have been changed after the fact? Everything else about audit is detail. A buyer's security reviewer will ask it as an architecture question, an inspector as an evidence question, and, in the worst case, an investigation as a question about a specific device on a specific day. The answer has to be the same in all three settings, and it has to have been true since the first record was written.
That is the part worth internalising: audit is not a feature you can add later. A trail that begins in month eighteen tells you nothing about months one to seventeen, and those are exactly the months an investigation will ask about. It is one of the few genuinely irreversible architectural decisions in this category, which is why Rydya made it at the start rather than when a customer first demanded it.
Questions
Can an administrator edit the audit trail?
No. Audit events are append-only, with no update path and no delete path, enforced at the database rather than by the application choosing to decline. They are also hash-chained, so altering an entry directly in the database breaks the chain and the tampering becomes detectable rather than silent.
What happens if the audit write fails?
The change fails too. The audit event is written in the same transaction as the change it records, so either both commit or neither does. There is no window where a change exists without its record, and no background job whose failure could go unnoticed at exactly the moment something interesting was happening.
How do we correct something recorded wrongly?
With an audited amendment: a new event that supersedes the old one, leaving both visible. Nothing is quietly edited. Closed financial records are never edited in place, and original amounts and currency are immutable. An inspector is not expecting a history with no mistakes in it; they are checking whether corrections are honest.
Does the audit trail prove our records are true?
No, and that limit is worth stating plainly. It proves the record is unchanged since it was written. It is evidence of process, not of reality. That claim is narrow deliberately, and the narrowness is what makes it defensible.
Is the audit trail isolated between organisations?
Yes. Audit events carry the organisation id and are protected by row level security like every other tenant record, so one tenant cannot read another tenant's history. Isolation on the audit matters exactly as much as isolation on the data, because the history is the data.
Keep reading
Role based access
The permission checks that decide what ever reaches the trail.
Compliance
What the trail is eventually for, and what Rydya will not claim about it.
Work orders
The transitions being recorded, including the gate that cannot be bypassed.
Security
Where this sits in the whole model, gaps included.
See it on your equipment
Live in an afternoon, useful the same week. A person replies, usually within one working day.
Contact us