Audit Log Integrity

Every Waafir data room keeps an audit trail — a record of who did what, and when. On its own, an audit log is only as trustworthy as the database it lives in: anyone with write access could, in principle, alter or delete a row and leave no trace. Waafir closes that gap with a tamper-evident audit trail built on a cryptographic hash chain and an external, immutable anchor.

This page explains the integrity model, how to verify it, and — importantly — exactly what the guarantee does and does not cover.

What "tamper-evident" means

Tamper-evident is a precise claim, and a stronger one than it sounds. It does not promise that no one can ever change a row; it promises that any change is detectable. If a row is altered, deleted, or inserted after the fact, the chain breaks in a way that a verifier will find and localise — even if the person who made the change had full database access.

That is the property auditors and regulators care about: not that the log is physically unchangeable, but that you can prove it wasn't quietly rewritten.

The hash chain

Each audit event is linked to the one before it with a cryptographic hash. For every row, Waafir stores:

• prev_hash — the hash of the previous event in the same organisation's chain.
• row_hash — sha256(prev_hash || canonical_serialize(row)), a hash that covers both this row's contents and its link to the prior row.

Because each row's hash incorporates its predecessor's, the events form a chain where tampering is self-revealing:

• Editing a row changes its contents, so its recomputed row_hash no longer matches the stored value.
• Deleting a row breaks the next row's prev_hash link.
• Inserting a forged row between two real ones breaks the following row's link.

Each organisation has its own independent chain, so a legitimate operation in one tenant — including a full account deletion — never looks like tampering in another tenant's log.

Events recorded before tamper-evidence was enabled carry no hash and are flagged as pre-chain; they are excluded from verification. Each organisation's chain begins at its first event after the feature was turned on.

The external anchor

A hash chain proves internal consistency, but an attacker with enough access could, in theory, rewrite the whole chain and recompute every hash. The external anchor removes that possibility.

Once a day, Waafir snapshots each organisation's chain head — the latest row_hash plus the number of chained rows — and writes it as a proof object to a dedicated Amazon S3 bucket protected by Object Lock (WORM — write once, read many). From the application's point of view that bucket is append-only: it can write new proofs but cannot delete or overwrite existing ones. The privileged action that could bypass the lock is held only by a sealed, out-of-band break-glass role, never by the always-on application.

The anchor is the integrity root. Even an attacker who rewrote the database and recomputed every hash could not forge the externally anchored head — so a mismatch between the live chain and its anchor is detectable.

Verifying a chain

Waafir ships a verification tool that walks an organisation's chain in order, recomputes every row_hash, and reports:

• PASS for an intact chain, or
• the exact first mismatch — the chain index, the offending event id, and the reason — for a chain that has been altered.

The verifier exits with a non-zero status on any failure, so a scheduled integrity check or a regulator's spot-check fails loudly rather than silently passing.

The same run also cross-checks the live chain against the most recent external anchor: it confirms the in-database head matches the anchored head, and that the row count has not regressed below the anchored count (which would indicate that recent events were truncated). The anchor cross-check reports PASS, a benign WARN when no anchor has been written yet (for example, a brand-new organisation), or a FAIL that fails the whole run.

For independent verification, an administrator can export a signed JSON bundle covering a date range. The bundle embeds the anchor cross-check and the covering anchor proofs, so a third party can confirm — on a fresh machine, without trusting Waafir's database — that the recorded head matches the externally anchored head end to end.

Retention modes: GOVERNANCE and COMPLIANCE

The anchor bucket retains proofs for 7 years, matching Waafir's broader data retention posture. Each organisation chooses one of two Object Lock retention modes:

GOVERNANCE is the default and already provides genuine tamper-evidence for every organisation. COMPLIANCE is for organisations under a hard regulatory mandate that requires absolute immutability. Opting in is irreversible: once an organisation is in COMPLIANCE mode, its anchored proofs cannot be deleted or shortened before their term expires, by anyone, and the mode cannot be downgraded. The opt-in is performed by an administrator behind an explicit, typed confirmation and is itself recorded in the tamper-evident log.

What the guarantee covers — and what it doesn't

Being precise about the boundary matters more than the marketing line.

What it proves:

• Tamper-evidence. Any modification, deletion, or insertion of an audit event after the fact is detectable via the hash chain.
• External integrity. The external WORM anchor and the verifier's cross-check make truncation or wholesale rewrites detectable, and the signed export lets a third party verify integrity independently.
• Immutability (COMPLIANCE mode). For organisations that opt in, anchored proofs are physically immutable for 7 years.

What it does not claim:

• It does not prevent a privileged user from changing a row — it makes the change evident. Prevention against the database administrator is the COMPLIANCE-anchor's job at the proof layer, not the live row's.
• A row_hash mismatch is not automatically an attack. Two lawful operations also break the chain by design and are handled as signed, auditable exceptions rather than silent failures:
  • a GDPR / right-to-erasure redaction of one actor's personal data inside a still-active organisation, and
  • a database point-in-time restore, which rewinds the live chain behind an already-written anchor. Each is reconciled with a signed in-chain record, so a reviewer can distinguish a lawful erasure or restore from genuine tampering.
• Pre-chain events (recorded before the feature was enabled) are excluded from verification and carry no integrity guarantee.

Why this matters

Most virtual data room providers offer an activity log you simply have to trust. Waafir's audit trail is cryptographically verifiable: you — or your auditor, or your regulator — can prove the record wasn't altered after the fact, without taking Waafir's word for it. For regulated diligence, fund administration, and compliance regimes that demand a defensible audit trail, that difference is the point.