How Can You Prove a Document Hasn't Been Altered? Hashes, Digital Signatures and Timestamps Explained

Showing that a record is unchanged is one of the four tests behind audit-ready records, next to finding, reading and attributing it. It is also a test that cannot be rebuilt after the fact, because the reference value has to be captured at signing.

What is document integrity verification?

Document integrity verification confirms that a file is the exact one that was signed, byte for byte. It rests on three checks. Each one answers a narrower question than its name suggests.

A hash is a fixed-length value computed from every byte of a file. NIST's Secure Hash Standard describes hash digests as a way to detect whether a message has changed since the digest was generated. If a single character in the file changes, the hash changes completely. On its own, a hash says nothing about who made the file or whether anyone approved it.

A digital signature is a value computed over that hash with a private key, so anyone with the matching public key can check it. NIST's Digital Signature Standard describes signatures as a way to detect unauthorized modifications to data and to authenticate the identity of the signatory. A signature answers "who committed to this exact content," not "who read it" or "was this person allowed to sign it."

A timestamp is a record that a given hash existed at or before a stated time. The IETF's Time-Stamp Protocol, RFC 3161, describes a time-stamping service as supporting assertions of proof that a piece of data existed before a particular time. A timestamp says nothing about whether the file was ever approved.

Why does proving a document is unchanged matter to compliance and audit teams?

A compliance officer asked to hand a signed board resolution to an auditor needs more than a statement that the file is unchanged. Signed PDFs, NAV reports and board resolutions can travel by email and file share, be re-exported, re-saved or renamed, and reach the auditor as one copy among several.

The compliance officer can say which copy is correct. The auditor wants to check that without relying on the party that produced it.

As of October 2026, the PCAOB's audit evidence standard, AS 1105, which applies to audits conducted under PCAOB standards, states that the reliability of evidence depends on its nature, its source and the circumstances under which it is obtained. In general, it describes evidence from a knowledgeable source independent of the company as more reliable than evidence obtained only from internal company sources. It also describes evidence the auditor obtains directly as more reliable than evidence obtained indirectly. Other audit frameworks are not described here.

That distinction shapes what a document check can offer. In practice, it matters who runs the check. If a colleague computes a file’s hash and emails it to the auditor, the value still comes from the company, and the auditor has to take the company’s word for it. If the auditor computes the hash personally and compares it with a value recorded outside the team’s control, the auditor has run the check. How much weight that carries in a given audit is still the auditor’s call.

It also matters how the check is described. A matching hash does not prove that a document is “genuine,” and a blockchain record is not “immutable.” Claims like these invite questions the check cannot answer. The opposite problem is a team that already has hashes, signatures and timestamps in place but cannot explain what each one shows, so the control goes unused.

Integrity also has a time dimension. ISO 14641, an international standard for systems that preserve electronic documents, describes its specifications as ensuring legibility, integrity and traceability of documents for the duration of their preservation. For regulator-ready documentation, this frames integrity as something maintained over a record's life, not checked once before an exam.

The same checks carry over to tokenized assets, where the token sits on a ledger but the NAV reports and offering documents behind it do not. Verifiable asset data depends on those documents being checkable in the same way. Verifying a tokenized asset's documents without relying on the issuer's word comes down to the same hash, signature and timestamp checks, though none of them shows that the content is accurate.

How do hashes, signatures and timestamps prove a document has not changed?

The three mechanisms combine in a fixed order: hash first, then sign, then timestamp. Each step narrows what a later verifier has to take on trust.

Step 1:  Hashing the file

A system reads the final file, byte by byte, and computes a cryptographic hash, for example SHA-256 from NIST's Secure Hash Standard. A later copy matches this value only if every byte is the same. Re-saving or re-exporting a PDF can change embedded data such as metadata even when the visible text looks identical, and the hash then changes too.

Step 2: Signing the hash

The responsible party signs the hash, not the whole file, with a private key linked to their identity. Anyone with the matching public key can then confirm two things: the hash has not been modified since signing, and which key holder signed it.

Step 3: Recording the time

The signed hash is timestamped or anchored, which creates a record that it existed at or before a given moment. A verifier who trusts the timestamp method can place the file in time without asking the signer.

Step 4: Independent verification

A later reviewer takes the file in hand and recomputes the hash. The reviewer compares it with the recorded value, checks the signature against the public key and confirms the timestamp. If all three check out, the file is the one that was signed, no later than the recorded time. If the new hash differs, the file has changed since, and the comparison does not show what changed.

Worked example: a signed board resolution, before and after

All values in this example are illustrative. A fund's board approves a resolution on June 3, 2026, and the CFO signs the final PDF. The system computes its SHA-256 hash, a 64-character value beginning a82d…, the CFO's key signs that hash, and the signed hash is timestamped at 13:58 UTC.

Before, without a recorded hash: nine months later, an auditor asks for the signed resolution. The compliance team finds three PDFs with the same file name in a shared drive and a thread of approval emails. The team can say which file is final, but the auditor has no way to check that without relying on the team.

After, with a recorded hash: the auditor receives one of those PDFs, recomputes its hash and compares it with the recorded value. A match beginning a82d…, a valid signature and a timestamp of 13:58 UTC on June 3 show that this file is the one signed with the CFO's key, no later than that time. A different value shows that the copy is not the signed version, and the auditor asks for the original.

‍

How do a hash, a signature and a timestamp differ?

A timestamp from a time-stamping authority and an anchor on a blockchain answer the same question, namely when a hash existed, but they ask the verifier to trust different things. RFC 3161 describes a time-stamping authority that may be operated as a trusted third party, so the verifier relies on that authority. NIST's blockchain overview describes blockchains as tamper evident and tamper resistant digital ledgers implemented in a distributed fashion and usually without a central authority, so the verifier relies on the ledger's network instead.

Neither document, in the passages cited here, ranks one approach above the other. Which one fits depends on the trust model the people checking the record already accept.

What are the common mistakes when proving a document has not been altered?

Calling a hash match "proof the document is genuine." A matching hash shows the file has not changed since the hash was computed. It says nothing about whether the content is accurate, whether the signer read it, or whether the transaction behind it was legitimate. A hash was never designed to answer those questions.

Hashing a file other than the one that was signed. If the hash is taken from a Word draft and the signed version is a PDF export, the two values will not match, even when the text is identical. The same happens when a signed PDF is re-saved before it is filed. A recorded hash only helps if it was computed from the exact file that was signed and kept.

Keeping the reference hash next to the file. If the recorded hash sits in the same folder or system as the file, whoever can change the file can usually change the hash too, and a reviewer still has to trust that system. The gain in reliability comes from a value the reviewer did not receive from the same source as the file, such as a timestamp from an independent time-stamping authority or a ledger entry outside the organization's control.

Treating every timestamp as equally strong. A date taken from the clock of the computer that saved a file can be changed by whoever controls that computer. A timestamp from an independent authority, or a ledger entry outside the organization's control, is harder to backdate without leaving a trace. The two can show the same date and still say very different things about who could have changed it.

Treating a hash as a change history. A hash comparison shows that a file differs from a recorded version, not what changed, who changed it or whether the change was authorized. A signature shows who committed to the original version. Who changed it afterwards, and whether that was authorized, has to come from a record of who had access and what they did, which is where an audit log, an audit trail and a tamper-evident record each prove something different.

Treating integrity as the end of the review. An auditor who can check a hash still needs a controlled way to see the file behind it. That is the job of secure data sharing with auditors and regulators: access granted per reviewer, instead of another copy sent by email.

Calling an anchored record "immutable." The NIST overview uses the narrower terms tamper evident and tamper resistant. The stronger word invites a challenge the mechanism cannot support.

Where does Filedgr fit?

A signed record can end up assembled at audit time from a shared drive, an e-signature log and email approvals. Each piece may be correct. Unless the hash was recorded at signing in a place a reviewer can check independently, the team is left asserting that a file is unchanged instead of showing it.

One way to close that gap is to fix each record when it is created: the file is hashed, the responsible party signs the hash, and the result is timestamped. Filedgr provides verification infrastructure built on that approach, the Prove step of Capture. Control. Prove. A record's SHA-256 hash is signed by the party responsible for it, anchored on a blockchain and kept with its timestamp in an append-only history, while the file itself stays in a Filedgr Vault with permissions set per recipient.

Since June 2026, the public Filedgr Explorer lets an auditor, an examiner or any other third party check a record's signature and blockchain transaction without a Filedgr account and without seeing the content. Proof Packages carry the hash, signature and timestamp with a file, so the same comparison can be run outside Filedgr.

Filedgr does not assess whether a document's content is accurate, whether the signer was entitled to approve it, or whether a record meets any particular rule. Those judgments stay with the people and processes responsible for them; Filedgr supports the compliance evidence, review and reporting workflows around them. The audit-ready compliance solution uses the same hash, signature and anchoring approach, and secure data sharing sets per-recipient permissions on the file behind a verified hash.

Review controls → https://www.filedgr.com/solutions/audit-ready-compliance?ref=blog-b