Evidence
Verify the audit chain
Verification covers the full chain, not a sample. It either verifies or it names the link that does not.
- Activity & evidence
- 4 min read
How the chain works
Every audit event is chained to the one before it with an HMAC-SHA-256 digest. The head of the chain is signed and anchored, so removing, reordering, or editing an event breaks verification at that point rather than passing silently.
This is what makes the difference between a log and evidence. A log tells you what someone wrote down; a verified chain tells you nobody has changed it since.
Running verification
Run a full-chain verification from the audit screen, and as part of runtime verification. Worth doing:
- After any plugin, WordPress, or PHP update.
- After a database restore or a host migration.
- Before exporting evidence someone else will rely on.
- At the start of any investigation, so you know the record you are about to read is intact.
Fail-secure writes
If an audit event cannot be written, the request does not proceed. The system declines to act rather than act unrecorded. That means a chain with a gap in it is not something normal operation can produce.
An action you did not take is recoverable. An action nobody can account for is not.
Backups and restores
Restoring the database to an earlier point restores an earlier chain. That is legitimate, and it verifies — but it is a different record from the one you had. If both matter, export the evidence before restoring.
Activity & evidence
Keep the boundary while you fix the problem.
A good fix restores intended behaviour without creating a second path around WordPress or the governed request lifecycle.