A word doing too much work
Search the audit trail and data integrity market and you will find the same vocabulary everywhere: immutable, tamper-proof, tamper-evident, append-only, cryptographically secured. Vendors across quite different architectures use identical language, which makes procurement comparison unusually hard and makes it easy to buy a guarantee weaker than the one you thought you were buying.
The distinctions are real and they are not subtle once you know what to ask. What follows is the question set we would want a buyer to put to us.
Four different guarantees, ranked by what they survive
Access-controlled. The record can only be modified by privileged users. This is the weakest form and the most commonly sold as immutable. It fails against exactly the scenario audits care about: a privileged insider, a compromised administrator account, or an organisation with a motive to revise its own history.
Append-only. The system's interface offers no update or delete operation. Better, and it constrains ordinary misuse. It still depends entirely on the honesty of the operator, because the underlying storage remains writable by whoever runs it. An append-only API over a mutable database is a policy, not a guarantee.
Internally tamper-evident. Records are hash-linked so that altering one breaks the chain. This is a real cryptographic property and a genuine improvement. Its limit is that if the operator controls the entire chain, they can recompute it. Detection requires comparing against something the operator does not control.
Externally verifiable. The integrity of the record is anchored to something outside the operator's control, so that a third party can verify it without trusting the operator or the vendor. This is the only tier that survives an audit conducted by someone with reason to be sceptical of you.
Most products in this market are tier one or tier two describing themselves in tier four language.
The questions that separate the tiers
- If your company wanted to alter a customer's record from last year, what would stop you? A satisfactory answer describes a mechanism, not a policy or a certification
- Can a third party verify a record without any cooperation from you or from us? If verification requires calling the vendor's API, the vendor is part of the trust chain
- What exactly is anchored - the record, a hash of the record, or a hash of a batch? Batch anchoring is legitimate and it changes what a single-record proof demonstrates
- What happens to existing proofs if you go out of business, get acquired, or discontinue the product? Evidence that expires with a vendor relationship is not evidence for a ten-year retention obligation
- What happens to proofs when the underlying cryptographic primitive is deprecated, and does re-anchoring preserve the original date?
- Can I export the proofs in a form a third party can verify with open tooling, or only through your interface?
Why the trust boundary is the whole question
Strip away the vocabulary and every claim in this market reduces to one question: for this evidence to be believed, who has to be trusted?
If the answer includes your organisation, the evidence is weakest exactly where it matters most, because the scenarios that generate audits are the scenarios where your organisation's account is in question. If the answer includes the vendor, you have narrowed the problem without eliminating it, and you have taken on a dependency with a corporate lifespan. If the answer is nobody, because the verification can be performed independently against something no participant controls, then the evidence holds regardless of what anyone believes about the parties.
That last position is worth paying for and it is also worth testing rather than accepting on assertion. Ask any vendor, including us, to demonstrate verification of a record by a party with no relationship to either of you. It is a short demonstration and it settles the question.
Where blockchain fits, and where it does not
Blockchain anchoring is one way to place the verification reference outside every participant's control, and it is the reason the technology is genuinely useful for this problem rather than merely fashionable. It is also not the only way, and its presence in a product does not by itself establish tier four.
A product can use a blockchain and still fail the independence test - if what is anchored is a summary the vendor computes, published on a chain the vendor operates, verified through a tool the vendor controls, the trust boundary has not actually moved. Conversely, a well-designed timestamping arrangement against multiple independent authorities can reach a comparable guarantee without a chain at all.
The technology is an implementation detail. The question is always the trust boundary. We set out our own view of where the technology earns its place in blockchain for compliance in 2026: beyond the hype, into the use cases, and the underlying mechanics in plain terms in what is cryptographic data integrity.
- Ask the tier-one test question first: what mechanism, not what policy, prevents the vendor from altering a record?
- Require a demonstration of third-party verification rather than accepting a description of it
- Check proof survivability against vendor discontinuity before signing a multi-year retention commitment
- Confirm the re-anchoring path for primitive deprecation
- Compare on trust boundary, not on vocabulary
If you want to run these questions against ROOTKey, the verification page lets anyone check a record independently, and you can create records to test with.
在邮箱中获取网络韧性洞见
关于数据完整性、合规与连续性的实用、可审计指南--发布即送达。