How ShareAndGo's Tamper-Evident Audit Trail Works
A look under the hood at our SHA-256 hash-chained audit trail — what it protects against and how to verify its integrity.
A peek under the hood at ShareAndGo's audit trail implementation. We think it's worth explaining in detail because most customers never look at the code, and "trust us" isn't a great security story.
What gets logged
Every meaningful event in a data room generates an audit entry. The list: document uploaded, document viewed, document downloaded, document deleted, document renamed, folder created, folder deleted, user invited, user access revoked, NDA accepted, permission changed, admin login, settings changed.
Each entry includes: a unique event ID, the data room ID, the action type, the user identity (email and IP address), a timestamp (to the second in UTC), a reference to any affected document or user, and free-form metadata relevant to the event.
The hash chain
Here's where it gets interesting. Each audit entry also includes a hash field. The hash is computed as:
SHA-256(previous_hash || event_id || action || user || timestamp || data)The "previous_hash" is the hash of the last audit entry in the same data room. The very first entry uses a known seed value. Every subsequent entry depends on every entry before it.
Why this matters
If someone tampers with an entry in the middle of the chain — changes a timestamp, deletes an event, inserts a fake one — the hash of that entry changes. The next entry's "previous_hash" reference is now invalid. When you verify the chain, the tampering is detected at the exact point it occurred.
To undetectably modify a log, an attacker would need to rewrite every subsequent entry AND update every stored "previous_hash" reference AND hope nobody has a snapshot of the hash chain from before the tampering. It's a much harder attack than just editing a database row.
How verification works
ShareAndGo's verification endpoint walks the chain from the beginning. For each entry, it recomputes the expected hash and compares it to the stored hash. If they match for every entry, the chain is intact. If any entry mismatches, the verification reports the exact entry where tampering was detected.
The verification can be run on demand (for example, when producing an audit report for a regulator), or automatically on a schedule. If tampering is ever detected, the data room is flagged and an admin alert is triggered.
What it doesn't protect against
Honest caveat time. This approach detects tampering after the fact. It doesn't prevent it. An attacker with database access can still rewrite the chain, and as long as they're careful to recompute everything consistently, the chain will still verify — against itself. What it can't match is any external snapshot or any hash that's been published to a third party.
For higher assurance, you'd want to publish periodic chain checkpoints to an external witness — a blockchain, a trusted third party, or a regulator. We're not there yet, but it's on the roadmap.