A Way That Auditors Can Verify Document History

How Auditors Can Verify Document History Using Blockchain Timestamps?

An auditor's basic problem with a document is simple to state. The file in front of them says one thing, and they need some reason to believe it said the same thing on the date the auditee claims. A cryptographic timestamp gives them a practical way to test that. If the auditee fingerprinted the file with SHA-256 at the time and anchored that fingerprint to a public blockchain, the auditor can recompute the fingerprint of the file they were given and compare the two. A match means the file is bit-for-bit identical to the one that existed at the recorded time. A mismatch means something changed.

That is a narrow claim, and the rest of this article is about using it well.

What "document history" means in an audit?

When auditors talk about the history of a document, they usually mean three separate questions:

1- When did this version exist? Was this contract, invoice, policy or report in this form before the period under review closed?

2- Has it changed since? Is this the same file that was signed off, or an edited copy?

3- What came before it? Which earlier versions existed, and in what order?

Ordinary tools answer these questions weakly. File metadata can be edited, and most people can change a "date modified" value in seconds. Email timestamps help, but they depend on someone else's server and on the email still being available. Internal logs are better, but they are controlled by the same organization being audited. None of this is dishonest, but an auditor has to treat it with appropriate skepticism.

Auditing standards already ask for this skepticism. ISA 500 and PCAOB AS 1105 both deal with the relevance and reliability of audit evidence, and both recognize that the reliability of evidence depends on its source and the controls around it. Evidence that sits outside the auditee's control is generally more persuasive than evidence that doesn't.

How a blockchain timestamp supports the check?

The mechanics are not complicated.

A hash function such as SHA-256 reads a file and produces a fixed-length string. Change a single character in the file and the string changes completely. Two different files will, for practical purposes, never produce the same one. SHA-256 is specified in NIST's FIPS 180-4.

To create a record, the file is hashed and only that hash is written to a blockchain. The block that contains it carries a time. Because many independent nodes hold copies of the chain, nobody, including the party that created the record, can quietly rewrite what was recorded or when.

To verify, the auditor does the reverse. They take the file they've been given, hash it themselves, and look for that hash on the blockchain. If it's there, the file existed, in exactly that form, at or before the time of the block.

Notice what the auditor doesn't have to do: trust the auditee's word, or trust the vendor's database. The check can be done independently.

How Certelo handles this?

Certelo calculates the SHA-256 hash locally in the user's browser. The original file stays on the user's device, and it isn't uploaded just to create the proof. The hash is then anchored to the Electra Protocol blockchain.

For auditees, this matters in practice. Contracts, payroll files and board papers are often confidential, and many organizations can't or won't push them to a third-party service. Because only the hash leaves the device, the record can be created without that exposure. Later, the auditor can verify using the original file, the hash, or the certificate information.

A practical workflow for auditors

Here is how this might look in an engagement. The example is hypothetical.

Suppose a company tells you its revenue recognition policy was approved and in force before the start of the financial year. You ask for the policy document. The finance team gives you a PDF and says it was approved in March.

If the company had timestamped that PDF at approval, you'd ask for the certificate details along with the file. You'd then hash the PDF you received and check that hash against the blockchain record. If it matches, you have independent evidence that this exact file existed by the recorded date. If it doesn't, you know the document was changed or that you've been given a different version, and you can ask why.

For multi-version documents, the same approach works across the sequence. If each approved version was timestamped as it was produced, you can establish the order in which versions existed, and check that the final one is the one actually used.

What to ask the auditee?

A timestamp is only as useful as the process behind it. A few questions help:

* Was the file timestamped at the time of approval, or retroactively?

* Who had access to the file before it was timestamped?

* Is the original file retained exactly as hashed? Even re-saving a PDF can change its bytes.

* Are there timestamps for earlier versions, or only the final one?

* What is the policy for when documents get timestamped?

The last question is the one that turns a one-off record into a control. A company that timestamps everything of a certain class as a routine step gives the auditor something far stronger than a single record produced on request.

What a blockchain timestamp does not prove?

This is where careless articles, and careless audits, go wrong. A timestamp record does not prove:

Authorship. It shows a fingerprint existed. It doesn't say who created the file.

Truthfulness. A false statement timestamped on Tuesday is still a false statement. The timestamp says nothing about whether the content is accurate or complete.

Completeness. It can't show that other versions didn't exist. If an auditee timestamps only the version they like, the record is silent about the rest.

Approval or authorization. Hashing a file isn't the same as someone with authority signing it off.

Anything before the timestamp. The record says "at or before." A document could have been fabricated shortly before it was anchored.

Legal admissibility everywhere. How courts and regulators treat this kind of evidence varies by jurisdiction.

On that last point, the EU's eIDAS Regulation (Regulation (EU) No 910/2014, Article 41) says an electronic time stamp can't be denied legal effect or admissibility just because it isn't a qualified one, while qualified time stamps carry a presumption of accuracy for the date and time they indicate. A blockchain timestamp from Certelo is not described here as a qualified electronic time stamp. Whether it's accepted in a given proceeding or by a given regulator is a question for local counsel.

So the right framing for the audit file is modest: this is one piece of corroborating evidence about integrity and timing, not a conclusion about the document's content or origin.

How this differs from other approaches?

Traditional trusted timestamping, such as RFC 3161 timestamp authorities, relies on a designated third party to sign the time. That model is well established and has its own legal recognition in several places. A blockchain approach replaces the single signing authority with a public ledger that anyone can inspect. Internal audit logs and document management systems are useful too, but they sit under the control of the organization being reviewed. Digital signatures bind a signer to a document, which a timestamp alone doesn't do. These are different tools and often work best together. A signed document that is also timestamped tells you both who approved it and when it existed.

Verifying a record, step by step

1- Obtain the file exactly as the auditee holds it, not a re-exported or re-saved copy.

2- Obtain the certificate details or the recorded hash from the auditee.

3- Compute the SHA-256 hash of the file yourself, or use Certelo's verification page, where the hashing happens locally.

4- Compare it with the recorded hash.

5- Confirm the hash appears on the Electra Protocol blockchain and note the block time.

6- Document the result in your workpapers along with the date you performed the check, in line with your documentation requirements (ISA 230 for example).

Frequently Asked Questions

Does a timestamp prove a document wasn't altered?

It proves that the file you hold matches the file that was hashed at the recorded time. If the hashes match, the content is identical. It can't tell you whether an earlier, different version existed.

Can an auditor verify without the auditee's help?

Yes, once they have the file and the recorded hash or certificate details. The blockchain lookup doesn't depend on the auditee or on Certelo's own database.

Does Certelo see the documents being timestamped?

No. The hash is calculated locally and the original file isn't uploaded just to create the proof.

Is this the same as a digital signature?

No. A signature ties a document to a signer's key. A timestamp shows the file existed at a point in time. They answer different questions.

What if the file is re-saved or converted?

Then its bytes change and the hash won't match, even if it looks identical on screen. This is why the exact original file needs to be retained.

Is a blockchain timestamp accepted as audit evidence?

Auditors decide what's sufficient and appropriate for the engagement. It can serve as corroborating evidence on integrity and timing. Legal acceptance depends on jurisdiction.

In short

A blockchain timestamp gives auditors something they rarely get: a check on a document's timing and integrity that doesn't depend on the party being audited. It works best as a routine control, applied consistently at the time documents are approved, and it should be read for exactly what it shows and nothing more. If you want to see how the hashing and verification work in practice, you can try Certelo's verification flow with any file.