External Data Verification: Checking Process Data Independently

An external reviewer needs a clear review assignment

The review assignment must specify which records and which claim are to be checked outside the source system. This determines the scope of the data, the method, and the accepted reference point.

Define the expected claim before receiving the data

The review assignment specifies the object, period, and required records. It also defines the technical claim: Is the aim to verify an unchanged file, the inclusion of selected entries under an earlier root, or the consistency of two log states? These proofs are not interchangeable.

The recipient also needs an accepted way to obtain the reference value and the required trust information. Only then can they assess whether the proposed package supports the assignment at all. Simply mentioning the cryptography used does not describe a verifiable procedure.

Example: A batch history for external review

In a fictional scenario, an organization provides the work steps performed, materials used, measured values, checks, releases, and corrections for a production batch. The export format unambiguously specifies the order, field types, time zone, and attachment structure.

Automated Compliance Evidence emerge from information connected during process execution. External verification adds technical verifiability; it neither creates missing process relationships nor completes a substantively inadequate statement.

An Electronic Batch Record can form the substantive source record for the batch; external verification then addresses a different layer — comparison with an independently secured reference point.

In this scenario, the authoritative records were already cryptographically bound in a specified representation at the end of the review period. The associated tree root was separately signed and secured with a trusted timestamp. For the later export, the reviewer receives selected unchanged records and their inclusion proofs against that earlier root. An export manifest describes the selection. The proofs establish inclusion in the bound set of records, not its substantive completeness.

The external reviewer can now check the following steps:

1. Is the package complete, and does it match the stated scope?
2. Are the agreed unchanged file bytes available, or can the specified canonical representation be reproduced?
3. Do the recalculated leaf hashes and the supplied proof paths lead to the previously secured tree root?
4. Is the signature mathematically valid, and is the key attributable to the issuer?
5. Does the timestamp match the verification value, and was the certificate verifiable at that time?
6. Are all events, reasons, and approvals required for the substantive review included?

The first five steps mainly concern technical verification. The sixth is a substantive assessment. Only their combination produces useful evidence for the specific review purpose.

What a verifiable data package needs to contain

Reliable verification starts with a clearly defined set of data, not with the hash value. The recipient must be able to identify which records are included, which period they cover, which version of the export format applies, and whether attachments or referenced objects are included.

A verification package may include, in particular:

• the exported process data and metadata,
• a unique package or evidence identifier,
• the operational and temporal scope of the export,
• the format version and a specification of whether unchanged file bytes or a defined canonical representation are used,
• the name and parameters of the hash algorithm,
• hash values for individual files or a shared verification root,
• a signature, certificate information, or timestamp evidence,
• an inclusion or consistency proof, where applicable,
• clear verification instructions and the expected result.

The claim depends on the chosen trust model

Every verification method needs at least one starting point that the reviewer trusts. This may be a public key, a certificate, a timestamping authority, a signed checkpoint, or a reference value held under separate organizational control.

The design should disclose who creates this reference point, who manages keys, how revocation and rotation are handled, and how the reviewer obtains valid information. An “independent” service is only genuinely more independent if its operation, permissions, and evidence are not all subject to the same uncontrolled ability to make changes.

Availability is also part of the model. Evidence that can only be checked through a service that is later shut down loses practical value. The export format, algorithms, certificate information, and required verification data should therefore be documented so that the intended offline or long-term verification remains possible.

A reproducible representation comes before the hash value

The same domain information can be encoded in different ways. Differences in field order, whitespace, time zones, decimal separators, or character encodings change the byte sequence and therefore the hash value, even when the represented content appears identical.

The method must specify what is being checked: either the exact archived file bytes or a jointly defined canonical representation of structured content. In the first case, the bytes are hashed without modification. In the second, the sender and reviewer need the same serialization rules, for example for numbers, dates, and field order. The format version used must then also form part of the evidence.

This specification is not a minor detail. Without a reproducible representation, the recipient cannot distinguish whether a different hash value results from an actual data change or merely a different technical output.

A hash value is a verification value, not yet independent evidence

A cryptographic hash algorithm maps a message to a fixed-length digest. In FIPS 180-4, NIST describes how such digests can be used to detect changes to a message since the digest was calculated.^[1]

For external verification, the recipient recalculates the hash over the data represented according to the agreed rules. If the result matches the protected reference value, the checked bytes match that reference point. If it differs, at least one prerequisite has not been met: the data, scope, order, format, or verification value differs.

An unprotected hash value delivered in the same package is not sufficient, however. Anyone able to replace the data undetected could generally also supply a new hash value. A separately protected reference value is what makes the check more meaningful in relation to the system that generated the data.

Hash chaining can additionally protect the order of successive entries. For an external reviewer, however, the decisive questions remain which chain state was anchored in a trustworthy way and how they obtain that reference point.

Digital signatures connect integrity to a signing key

A digital signature can provide evidence that signed data has not been changed undetected since signing and that the signature was created using a particular private key. FIPS 186-5 describes digital signatures as a means of detecting unauthorized modifications and authenticating the identity of the signatory.^[2]

The recipient needs the corresponding public key and a reliable attribution of that key to the claimed issuer. Certificates, certificate chains, revocation information, and defined trust anchors are therefore part of the verification model. A mathematically valid signature alone does not establish whether the signatory was authorized at the relevant time or whether their identity was properly checked.

The meaning of the signature must also be defined. It may merely identify the technical export service, represent a substantive approval, or confirm that a particular organization issued the package. These claims must not be conflated.

Trusted timestamps provide evidence of an earlier data state

For many reviews, what matters is not only which data is available, but also whether the associated verification value already existed at a particular time. RFC 3161 describes a Time-Stamp Protocol for this purpose. A Time Stamping Authority associates the data's hash imprint with trusted time information and signs the timestamp token.^[3]

The trusted authority does not need to receive the actual operational content. Under the RFC, only the hash imprint is transmitted. A later verification checks the data, hash imprint, timestamp token, signature, and certificate status together.

The timestamp supports evidence that the specified data imprint already existed at the confirmed time; the stated time accuracy and the timestamping authority's policy must be taken into account. It does not prove when the real operation took place or whether a time stored in the data is correct. Secure time sources, process context, and organizational controls remain necessary to establish that connection.

Published checkpoints allow verification without disclosing the data

A tree structure can combine many individual records into a shared root value. An individual record can then be checked against this root using an inclusion proof, without disclosing all the other content.

RFC 9162 uses Merkle trees for Certificate Transparency. The method supports inclusion proofs for individual entries and consistency proofs between earlier and later states of an append-only log.^[4] Its specified use case concerns certificates; the technical principle nevertheless shows how signed checkpoints and compact proofs can be kept separate.

For operational process data, a root value regularly secured outside the operational system can serve as a checkpoint. The recipient then receives only the data they are permitted to check, together with the associated proof path. Other batches, individuals, or trade secrets do not need to be part of the disclosed package.

What a failed proof means

A failed verification is initially a technical finding. It may mean that data has been changed. Other possible causes include an incomplete transfer, an incorrect export format, different canonicalization, a missing proof path, an expired certificate, or unavailable trust information.

The result should therefore report more than “valid” or “invalid.” It should identify the stages checked: data scope, hash calculation, signature, certificate chain, timestamp, inclusion, and consistency. This makes it clear which prerequisite caused the check to fail.

A technical error must neither automatically be treated as proof of tampering nor dismissed as a mere formatting problem. It triggers an investigation in which the cause, affected data, possible consequences, and required actions are assessed in a traceable way.

Verifiability does not require publishing operational content

External verification should follow the principles of purpose limitation and data minimization. The recipient receives only the content needed for the review assignment. Personal information, trade secrets, and data from other batches can be excluded, pseudonymized, or separated through selective proofs. However, redacting or pseudonymizing content within an already hashed file creates a different byte sequence. The original file proof no longer applies unchanged. The recipient must be able to identify whether they are checking an original or a derived representation; connecting the latter to the earlier evidence requires a method designed for that purpose.

A published hash value is not a readable copy of the original content. However, small or predictable value ranges may allow inferences or exhaustive guessing. Checkpoints should therefore disclose no unnecessary information. Random binding values can form part of a protection method designed for this purpose. Tree structures enable proofs for selected units, but do not by themselves prevent small value ranges from being guessed.

Data provenance also helps explain which operations and sources gave rise to the exported claims. It too must be disclosed only to the extent required for the specific review.

Long-term verification requires renewal

Cryptographic methods do not remain equally reliable indefinitely. Algorithms may weaken, keys may be compromised, certificates may expire, or trust services may be discontinued. Evidence that is valid today is therefore not automatically verifiable throughout every retention period.

RFC 4998 describes Evidence Records for long-term evidence of the existence and integrity of digital data. The specification provides for archive timestamps and their renewal before the cryptographic mechanisms in use cease to be suitable.^[5]

A long-term strategy must therefore specify when evidence is renewed, which earlier information is included, and how algorithm changes are documented. The original data must not be replaced by a merely current signature; instead, the new layer of evidence must extend the existing evidence chain in a traceable way.

Internal control and independent review operate at different levels

Within an operational system, roles, permissions, approvals, and logs control who may create or change data. These controls are necessary, but fall within the same organizational and technical area of responsibility as the data itself.

External verification moves the checkpoint. An auditor, client, laboratory, business partner, or authority can compare a supplied package with evidence whose integrity does not depend solely on what the application currently displays. Depending on the method, this reference point is held by an independent trusted authority, a separately operated verification service, or a previously published log.

“External” therefore does not necessarily mean “public.” Operational and personal data does not need to appear on the internet to be verifiable. Often, securing a hash value or an aggregate root derived from it outside the operational system is sufficient. The actual content remains within the protected area of responsibility and is provided only for a specific review purpose.

External verification requires neither a public blockchain nor disclosure of operational data.

What external data verification does not do

Cryptographic evidence alone does not make an organization compliant.

Data integrity depends on appropriate capture, assignment, control, retention, and correction throughout the lifecycle. External verification supplements these controls with an independently traceable technical check; it does not replace them.

It does not prove that an initially recorded measurement was factually correct.

It does not replace a substantive review, release, or regulatory decision.

The result must be more precise than “valid”

A useful conclusion identifies the units checked, the reference point used, and the verification steps that succeeded or failed. A matching inclusion proof confirms inclusion in the bound set of records; it does not confirm that the selection is complete.

The recipient can use this as the basis for further investigation. Missing records, unclear trust information, and unresolved substantive questions must remain visible, even if individual cryptographic verification steps were successful.