Audit trail
Every file, every action, on the record.
When a question comes up about a file weeks later, memory is not an answer. RoverDrop keeps an append-only audit trail on every packet: who submitted it, who viewed and downloaded it, who accepted responsibility, who it was reassigned to, and who filed it, each with a name and a timestamp. Nothing is inferred, and nothing can be quietly changed.
No account or email needed for the demo.
“Let me look through my sent folder”
When files move by email and shared drives, the record of what happened is scattered across inboxes, folder timestamps, and people's memories. Reconstructing it after the fact is slow, incomplete, and easy to dispute. A folder's modified date tells you a file changed, not who changed it or why. An email thread tells you what people said, not what they actually did with the files.
An audit trail is the opposite: a single, ordered, per-packet record built as things happen. It does not depend on anyone remembering to note something down, and it cannot be reshaped later to fit a story. That is what makes it useful when it matters.
What a real audit trail has to include
Five things, on every entry. Drop any one and the trail stops being something you can rely on.
The actor
A specific person, not a role or a shared account. Every field crew member and office tech has their own login so the trail names an individual.
The action
What happened, from the exact list of possible events: submitted, viewed, downloaded, accepted, commented, reassigned, filed. No vague "updated."
The target
Which packet, and where it matters, which file. A download event names the file that left; a submit event names every file that arrived.
The time
A server timestamp taken when the event occurred, not when someone got around to logging it. Times are consistent across the whole trail.
Immutability
Entries are appended and never changed or removed. A trail that can be edited after the fact is not evidence of anything.
For the full checklist, read what an audit trail for field file transfers should include.
One packet, in full
A trail that separates looking from owning
Notice that viewing and downloading are recorded, but they do not transfer responsibility. The trail makes the distinction visible: the office can read a packet as many times as it likes, and ownership still sits where it did until someone accepts.
- SubmittedFrank Field5 files · 218 MB · checksums verifiedJul 2 · 9:14a
- ViewedDana OfficeOpened packet detailJul 2 · 9:38a
- DownloadedDana Officeraw_data_day2.zipJul 2 · 9:40a
- AcceptedDana OfficeResponsibility transferredJul 2 · 10:02a
- CommentedDana OfficeMissing the control sheet?Jul 2 · 10:05a
- ReassignedDana OfficeTo Sarah LeadJul 2 · 11:15a
- FiledSarah LeadPlaced in project archiveJul 2 · 4:20p
The same events feed the read-only API and signed webhooks, so the trail can flow into whatever system your firm uses for records, without anyone re-keying it.
Proof at the start, archive at the end
The audit trail begins with proof of delivery, the verified receipt that opens the record, and it points, at every step, back to the write-once archive copy of the files themselves. Together they answer the three questions any file dispute comes down to: what was sent, what happened to it, and where the original still lives.
Related
See it in motion
Read a packet's whole history
Open the demo, work a packet through accept and file, and watch the audit trail record every step with a name and a time. No account or email required.