How Does an Auditor Verify an Evidence Package?

One of the most common sentences in an audit is "our records cannot be altered." An experienced auditor notes it down but does not treat it as evidence, because the party making the claim is the party keeping the records. This article is about what can replace that sentence, and which checks an auditor can run at their own desk.

The Question an Auditor Cannot Answer

When an auditor is handed a screenshot, a spreadsheet or a list pulled from a database, they hold exactly one fact: this file was given to me today. When it was produced, whether it was edited after that, and which system it came from cannot be read from the file itself.

This is why audits drag on. Weak evidence calls for more samples, and more samples produce more questions. The way to strengthen evidence is not to send more documents but to make the document you send checkable by the auditor alone.

What a Verifiable Package Contains

A verifiable evidence delivery is not a single file but a small set of them. The shape of that set is standard and identical in every delivery, so the auditor learns one procedure.

• The data itself, in plain text and machine readable form. Being readable by eye matters: the auditor should be able to see what was signed.
• A manifest, listing which files went into the package and the SHA-256 digest of each. Removing a file from the package is caught by this list.
• A signature over the manifest, asymmetric, so the verifier never needs the private key.
• The public key, the only thing needed to check the signature. Nothing further is requested from the organisation.
• A verification script, as a convenience rather than as part of the evidence. Everything it does should also be doable by hand.

SQL Change Guard uses this same wrapper for all three of its deliveries: the evidence dossier for a single request, the package of daily anchors and the package of raw audit records. They answer different questions but share one shell.

Four Steps, Four Separate Questions

The verification steps do not substitute for each other. One passing does not make another pass, and that distinction decides what the auditor can write in their report.

1. Have the files changed? You read the list in the manifest and recompute the SHA-256 digest of each file. A row that does not match means that file changed after the package was produced.
2. Who did the manifest come from? The signature is checked against the public key in the package. If it passes, the manifest came from the installation holding the matching private key and has not changed by a byte since.
3. Is the key the right key? You compute the fingerprint of the public key and compare it with the value the organisation published outside the package.
4. Is the content internally consistent? The first three check the wrapper. The fourth looks at the content: whether the records link to each other, and how they compare against a value received earlier.

The Step Everyone Skips: The Fingerprint

The third step is the one most often skipped, and skipping it makes the second step meaningless. Checking a signature inside a package against a key inside the same package is self certifying: anyone can generate their own key pair, put both into the package, and the check will pass.

The fingerprint breaks that loop. The organisation publishes the fingerprint of its evidence signing key through a channel independent of the package: an annex to a contract, an audit manual, a fixed page on a corporate portal. The auditor computes the fingerprint of the key inside the package and compares it against that external value. Only then does the signature become proof of origin.

The fingerprint has to be taken from the key itself, not from the text file that carries it. The same key can be written with different line endings on two installations; the digest of the text changes while the key does not. That is why the digest is taken over the binary representation of the key.

What Verification Does Not Prove

Honesty is more convincing in the long run. When a verification passes, the following has been shown: the package has not changed since it was produced, it came from the installation holding the declared key, and the records inside it link to each other.

What is not shown is that the entry was true on the day. A seal shows a record is early, not that it is correct. False information can be signed too, and the signature does not make it true. The auditor still has to judge the content; what verification does is take the possibility of later alteration off the table.

The second limit: an action that produced no record at all does not appear in an evidence package. What surfaces an intervention made outside the product, straight against the database, is not the signature but a separate trail kept at the database level. The two mechanisms answer different questions and neither replaces the other.

What the Organisation Has to Do

Producing verifiable evidence is not technically hard, but it requires three organisational decisions.

• Key ownership. The evidence signing key belongs inside the organisation's own key management discipline. No key should be embedded in the product; the organisation sets it.
• Publishing the fingerprint. Done once, updated on rotation. Without it the signature check collapses into a self certifying exercise.
• An installation identity. Every installation needs its own label. Files from two installations sharing one label are interchangeable, and the check "did this package come from our installation" quietly stops meaning anything.

Once those are in place the audit conversation changes. "Our records cannot be altered" gives way to "take this package, run this command, see the result for yourself." The second sentence is far stronger than the first because it can be tested.

Frequently Asked Questions

Do we have to hand our signing key to the auditor?

No, and you should not. The signature is asymmetric: verification uses the public key, and the public key travels inside the package. The private key stays with you. The key that signs the audit chain is a separate one and never leaves at all; the two most valuable checks are designed not to need it.

Does verification need special software?

It does not, and that is a design decision. Making the person who must independently check your evidence install something from you weakens that independence. The PowerShell that ships with Windows, or openssl, covers every step. The script inside the package is a convenience only.

Who should be able to produce a package?

It should be limited by a dedicated permission. The package holds the full text of scripts, which servers they ran on and who approved them; it is a sensitive file that can leave the organisation. Producing it is also an event and should be written to the audit trail. That record is also the only way to show afterwards that deliveries were made regularly.

If verification fails, does that mean tampering?

Not directly. The most common cause is a file damaged in transit or a mistake while unzipping. The right move is to request the package again and repeat the check. If it fails a second time, that is a finding and the reason should be requested from the organisation in writing. What matters is that the outcome is not left ambiguous either way.