Skip to content
RUEN
How-toQA & inspection

Verify the audit chain integrity

Audit trail records are chained by hashes: each carries a fingerprint computed over the fingerprint of the previous one. The check recomputes the whole chain from the start and shows whether it is intact — proof that the trail has not been rewritten.

Who and when

Section titled “Who and when”

QA & inspection — the QA specialist or auditor. You need the “run the hash-chain check” permission (audit.verify); holding it at any level inside the organization, such as a study, is enough. Modules can never hold this permission.

Verify the chain before an inspection or audit, before handing over a trail export or an inspection packet, and periodically — per your procedure.

Before you start

Section titled “Before you start”
  • You hold audit.verify.
  • Keep in mind: the check reads the whole organization trail, not just one study, and takes time on a large trail.
  • To compare the chain head with an anchor, have a previously assembled inspection packet at hand.

Steps

Section titled “Steps”

  1. Open the study → Audit trail. At the bottom of the screen is the Trail integrity block.

  2. Click Verify trail integrity. While the chain is recomputed, the button shows “Verifying…”.

  3. Read the result:

    • Chain intact — “The whole organization trail is verified — N records” and the Chain head — the fingerprint of the last record;
    • Chain broken — “Trail integrity is broken at record No. N” — the number (seq) of the first broken record.

  4. Record the result per your procedure: the date, the number of records checked and the chain head.

Verify from Admin

Section titled “Verify from Admin”

An administrator sees the same check on the Admin overview — the Audit trail integrity row, button Verify (then Verify again). If the chain is broken, the row offers Open audit trail at the broken record.

Compare the chain head with an anchor

Section titled “Compare the chain head with an anchor”

Every inspection packet build records the chain head (an anchor) and puts the whole anchor history into the packet. Find the latest anchor in a previously stored packet and make sure the live chain passes the check and continues it: the records made before the anchor have not changed.

What happens

Section titled “What happens”
  • The check only reads the trail — neither the data nor the trail itself changes.
  • The whole organization chain is recomputed, from the first record to the last; a range cannot be chosen.
  • The result stays on screen until you leave the page.

If it doesn’t work

Section titled “If it doesn’t work”
  • No Trail integrity block or verify button — you do not hold audit.verify at any level of the organization. Contact your access administrator.
  • “Verification failed” — an execution failure (e.g. network or server), not a verdict on the chain. Run the check again.
  • Chain broken — this is not an interface error but a signal of possible tampering. Do not try to “fix” the trail: inform the quality lead, open the trail at the reported record, record the result and keep the latest inspection packets — their anchors are needed for the investigation.

Next

Section titled “Next”
Export the audit trailThe CSV for verification — recompute fingerprints outside the system.
Assemble the inspection packetA packet with full chain verification and the anchor history.
Audit trailAppend-only, the hash chain and anchoring in plain terms.

More detail

Section titled “More detail”

What the check catches

Section titled “What the check catches”

If someone tries to change, delete or insert a record in the middle, the fingerprints stop matching. The check detects content edits, record deletion, insertion in the middle (a gap in the numbering) and substitution of a reason.

Why anchors

Section titled “Why anchors”

The audit table is protected by PostgreSQL triggers, and the application’s runtime role has no right to change the trail. A holder of schema-owner or DBMS superuser rights can technically remove the protection — but not unnoticed: the anchors in previously issued inspection packets will show the discrepancy. The packet itself is the external write-once medium: placing it into your own WORM or eTMF store gives you a dated copy against which the live chain is later verified. This makes it possible to prove integrity even if you assume that someone with database access recomputed the entire chain. How often anchoring happens is set by your packet-building procedure.