Append-only events, cryptographically chained, with full traceability and verifiable integrity.
Why an ordinary log is not enough
Almost every application writes a log. Few can prove that the log has not been changed after it was written. The difference matters exactly when the log is requested as evidence: at an inspection, in litigation, after a security incident.
A log that can be edited by someone with database access says nothing about the past except that this is how it looks now. The auditor’s question is not what the log says, but how we know it says what happened.
How the chaining works
Events are written once and never changed — append-only. Each event carries the cryptographic fingerprint of the one before it, so the events form a chain. Changing an event in the middle changes its fingerprint, which breaks the link with all the ones after it, and the break shows up at verification.
Verification does not require trust in the system: the fingerprints along the chain are recalculated and compared. Either they match from one end to the other, or the exact point of discontinuity is shown.
Every relevant operation on a document or an entry produces an event: who did it, what it touched, when. For registers this includes cancellations and rectifications, which stay on record with their reason, instead of erasing history.
- events written once, with no later change;
- cryptographic chaining between consecutive events;
- an integrity check that shows not only that something changed, but where;
- structured export to security monitoring systems.
What it is used for, concretely
To reconstruct an incident: what happened, in what order, who was involved. To answer a supervisory authority, where a statement must come with evidence. To settle an internal dispute about who approved a document and when.
And for something less spectacular but more frequent: to prove that nothing happened. A continuous, verifiable audit chain is, most of the time, the proof that the system worked normally.
The written policy and the applied policy
Almost every organisation has compliance policies. Few can prove they are applied uniformly. The difference shows at the audit: the policy exists in an approved document, but the proof that it was followed in every case has to be gathered by hand, from several places.
The reason is simple. A policy applied by people depends on their attention on a busy day. One applied by the system is applied the same way every time, including when nobody is looking.
What is automated
Retention: each document category gets its period, calculated from the relevant date, and expiry triggers the selection process, not a silent deletion.
Access: rights come from the role and from the classification of the document, not from individual requests handled one by one. A document classified under a special regime does not become visible because someone forgot to restrict a folder.
Information protection: confidentiality markings are applied per category and determine what can be done with the document — who sees it, whether it can be sent outside, whether it can be printed.
And what cannot be automated stays explicit: exceptions are requested, approved and kept on record, instead of being convenient silences.
- retention periods applied per category, automatically;
- rights that come from role and classification;
- confidentiality markings with concrete effects;
- exceptions requested and approved, not silent.
Proof, not declaration
The value of automation shows at an inspection. The question “how do you make sure the retention policy is applied” is answered with the configuration and the log, not with a written procedure and a promise.
The same logic applies to data subject requests, periodic reporting and internal inspections: the system is queried, not reconstructed from files.
Questions and answers
What happens if someone changes the database directly?
The change breaks the chain of fingerprints, and the integrity check flags it, showing the position of the discontinuity. The log does not prevent an intervention at database level, but it makes it visible.
How long are audit events kept?
The retention period is set by the organisation’s policy and by the legal requirements of your field. The platform does not impose a duration; it applies the configured one.
Can the log be exported to a SIEM?
Yes, through structured export. The actual format and frequency are set at implementation, depending on the monitoring system you use.
Which operations go into the log?
Operations on documents and entries — creation, consultation, change, cancellation, rectification — together with the author and the moment. The exact set can be detailed in a technical discussion.
Can policies change after implementation?
Yes, through configuration. The change stays on record, like any other configuration change.
What happens to documents already in the system when a policy changes?
The behaviour is set at configuration: the new policy can apply from a date onwards or retroactively, as the organisation decides.
Can automation delete documents by mistake?
Expiry triggers a selection process, not a direct deletion. Disposal remains a recorded decision.
Does it cover the specific requirements of our field?
Policies are configured on the categories and periods that apply to your organisation, including those from sector legislation.