Anchoring: What Shows That a Record Is Old?

A hash chain is the best known way to protect an audit trail, and it genuinely works. But there is one gap it cannot close on its own, and an experienced auditor finds that gap in the first half hour. This article is about what the gap is and how an anchor delivered outside the organisation closes it.

The Gap a Chain Cannot Close

In a hash chain every record carries the digest of the one before it. Change a record in the middle and every digest after it stops matching. That rules out the cheap interventions: inserting a record, quietly correcting a single row, deleting one entry and putting something else in its place.

Here is the gap: someone holding the key that computes the chain can rewrite the past and recompute the whole chain. The result is a perfectly self consistent chain. The product's own verification screen reports the chain as intact, and it is telling the truth, because the question it asks is whether the chain is consistent, not whether it is the same chain as yesterday's.

This is not a theoretical possibility. It is precisely why audit exists: an organisation's own assessment of its own records is not accepted as sufficient. So a control has to have an answer to the rewrite the past scenario.

What an Anchor Is

An anchor is a very short sentence: "as of this time today, my last record has this number and this digest." That sentence is signed and delivered outside the organisation at regular intervals.

Months later the auditor takes out the old anchor and asks the organisation for the raw records covering that number. If the digest of that row today matches the value in the anchor, the record has not changed since the day the anchor was delivered. If it does not, the past has been rewritten, and that is the strongest tampering indicator an audit trail can carry.

The most important property of this comparison is that it needs no secret key. The auditor asks the organisation for no secret, connects to no system and installs no software. They simply compare two values that reached them at two different times.

Why It Has to Have Been Delivered Earlier

All of the anchor's strength comes from when it was delivered. An auditor who receives both the records and the anchors from the organisation on audit day has verified nothing: both files were produced at the same moment by the same party. Whoever rewrites the past can regenerate the anchors as well.

So anchor delivery should follow its own calendar rather than the audit calendar. A monthly or quarterly rhythm is enough. What matters is that delivery is regular and independent of the audit.

The delivery interval sets the resolution of the evidence. An anchor delivered monthly leaves a one month window in which something could have changed. The same applies to anchors produced daily but delivered quarterly: the window is set by delivery, not by production.

Who Should Receive the Anchor

The right recipient is a party whose copy the organisation cannot later change. In practice there are a few options and they all serve the same purpose.

• The internal audit function. Inside the organisation but outside the IT line. For most organisations this is the most practical starting point.
• The external auditor. The strongest option, because no authority inside the organisation reaches that archive. The interval is usually longer since it follows the audit cycle.
• A timestamp authority. Not a person but a service; by signing the digest of the anchor it lets a third party state the date. It complements the other recipients rather than replacing them.

Whoever the recipient is, the delivery itself should be recorded. "We deliver regularly" is also a claim, and an auditor will ask for evidence of it. Writing each delivery into the audit trail as an event answers that question.

The Organisation Checking Itself

An anchor is not only useful to the auditor. The organisation can compare the anchors it signed in the past against today's records on a schedule, and it should do so automatically. There are two possible outcomes.

If they match, the organisation carries an assurance into the audit: the past records are intact. If they do not, it learns months before the auditor does and has time to investigate. The difference between a finding raised in an audit and a warning produced by your own control is the difference between being prepared and being caught out.

SQL Change Guard runs that comparison as a step in its daily integrity job and raises a critical notification when it finds a mismatch. The result of the check is also written into the signed manifest of the anchor package delivered to the auditor. Because the manifest is signed, editing that line to hide a finding breaks the signature.

Setting Up Your Own Anchoring

Setting up anchoring raises five questions, and none of them are technical.

• How often is it produced? Daily is a good default. Production is cheap; the cost sits in delivery.
• How often is it delivered? This sets the resolution of the evidence. Monthly is a reasonable balance for most organisations.
• Who receives it? This should be written down, and a change of recipient should itself be recorded.
• How will the recipient store it? An immutable archive is not required, but the date of receipt has to be evident. An anchor with no date carries no evidential weight.
• What happens if there is a gap? A period with no anchors between two deliveries is not tampering by itself, but it needs an explanation. The right behaviour is for the package to report such gaps on its own.

With answers to those five questions, the weakest point in your audit trail is closed. Without them, the chain you hold is consistent only with itself.

Frequently Asked Questions

What does an anchor carry, does record content leave the organisation?

An anchor carries only the number and digest of the last record, the time it was produced and the installation identity. It contains no record content, no script text and no personal data. Handing an anchor outside the organisation is therefore not a data disclosure, and it passes a privacy review easily.

Does an anchor replace a timestamp?

No, they solve different problems. An anchor shows that a record has not changed since a given date and draws its strength from when it was delivered. A timestamp takes the date from an external authority rather than from the organisation's own server clock. Used together they give separate support for the content and for the date.

What happens if an anchor is deleted?

It can be deleted inside the organisation; no software can stop a fully privileged user from deleting it. But an anchor already delivered sits somewhere the organisation cannot reach and cannot be taken back. Detecting deletion is only possible against earlier deliveries anyway; deleting an anchor that was never delivered leaves no trace anywhere. This is why the delivery routine matters as much as the mechanism.

Why can the record count differ from the last record number?

Because the number is an auto incrementing counter and rolled back transactions consume numbers too. An anchor should therefore carry the highest number it saw rather than a count: the row the auditor compares is the one at that number. An anchor carrying a count produces a comparison that fails even in normal operation.