A defensible audit trail does two things most trails do not. It distinguishes the kind of access, and it records permission changes on the same timeline as the reads. Miss either and the log will tell you that something happened without telling you what, which is worse than useless, because it reads like evidence until somebody examines it.
The failure this prevents
Eighteen months after close, a buyer says a supplier agreement carrying a change-of-control clause was never disclosed. The seller's position is that the file sat in the room from week one and the buyer's own counsel opened it. Someone pulls the log.
If the log says counsel@firm.com accessed Supplier_Agreementson a date, the seller has nothing. That line cannot separate counsel expanding a folder from counsel reading page 41. It does not say which version of the file was in place. It does not say what permission counsel held, and if they were restricted to file names, “accessed” means they saw a filename and no content at all. A trail that keeps those states apart settles the same argument in one row.
Viewed and downloaded are different events
They answer different questions and carry different consequences. A view is bounded: the page is rendered and watermarked server-side, it is visible while access lasts, and revoking access ends it. A download is a hand-over. A copy now exists outside the room, and revoking access does not bring it back.
A disclosure argument needs views, because the point is that they saw it. A leak investigation needs downloads, because the point is who holds a copy and when they took it. A system that writes both as a single accessed event supports neither.
| Criterion | Event recorded | Why it matters in a dispute |
|---|---|---|
| Did they open the file? | document.view | Separates rendering a document from expanding the folder that contains it. Merge the two and browsing looks identical to reading. |
| Did a copy leave the room? | document.download | A download survives revocation. This is the only row that tells you a file still exists on someone else's machine. |
| Were the original bytes handed over? | document.file_url_issued | A signed link to the unrendered original is a download under another name. Recorded with the window the link stays live and whether a watermark was required. |
| Did they only see the name? | document.detail, document.list | Metadata access. Counting it as a view overstates what the participant actually saw, which is the fastest way to lose an argument you should win. |
| Was it printed? | document.print | Paper leaves no further trail. This event is the last point at which the copy is still traceable to a person. |
| Who could see it that day? | access.grant, access.revoke, access.modify | Reconstructs the permission a participant held at the moment of a read. Without it, “they viewed it” is contestable. |
| Which version did they see? | document.version.create, document.version.restore | Ties a read to a specific revision. Otherwise a later upload quietly rewrites what the log appears to say. |
| Who tried and failed? | auth.login.failure | Recorded at warning severity. A trail with no failed attempts anywhere in it is not watching, it is reporting. |
| What did the AI surface? | ai.query | An assistant that can quote a document is a read path. If AI questions are missing from the trail, part of your access record is missing. |
The third row is the one nobody asks about. In Sifrsys a signed URL to the original bytes used to be recorded as document.view, so a silent handover of the untouched file looked identical in the log to somebody glancing at page one. It is now its own event. Every product has a path where the browser cannot render a file type and hands over the original instead. Ask any vendor what that path writes to the log.
Five checks to run before you rely on one
1. Try to delete a row. Sign in as the room owner during a trial and look for a delete control on a log entry. If one exists, the log is a report, not evidence. In Sifrsys the audit_log table carries a BEFORE UPDATE OR DELETE trigger that raises an exception, so no application path edits a row in place.
2. Ask how tampering would be detected, not just prevented.Prevention is a policy. Detection is a property. Each Sifrsys row stores a SHA-256 hash over its own id, event type, actor, resource, timestamp and the previous row's hash, chained per organisation. Remove a row and every later hash stops reconciling.
3. Export it during the trial.Ask for the whole trail as CSV or JSON, with the hashes, without opening a support ticket. A log you can only read inside the vendor's interface is a log you lose when the subscription ends. Check the plan you are actually buying rather than assuming export sits on the tier you were shown.
4. Ask whose clock.Server-side UTC only. A timestamp reported by the viewer's browser comes from a machine the viewer controls, and the first thing a motivated participant changes is the clock.
5. Ask what identity is stored. The email address and the file name as they were at the time, or foreign keys resolved against live tables at read time? A trail built on keys alone goes blank when a user is deleted and quietly misreports when a file is renamed. Sifrsys writes actor_email and resource_name onto the row itself, alongside IP address and user agent.
The part people forget: permissions belong on the same timeline
A read event is only meaningful next to the permission that allowed it. If a participant was moved from name-only visibility to full view on a Tuesday, every read before Tuesday means something different from every read after. That is why grants, revocations and modifications have to sit in the same append-only stream as the views rather than in a settings history somewhere else. It is also why the permission tier a participant sits in is worth understanding before the room opens, which is the subject of fence view and what it actually prevents.
The same holds when you change vendors mid-process: a trail that starts on day one of the new room has a hole in it exactly where diligence began, which is the expensive part of moving between data rooms. The checks above are a subset of a longer list in our data room security checklist, including the questions we find uncomfortable to answer.