SHA-256 in audit records, explained without the legal hype
What a SHA-256 digest in a condition record can show, how AuditIt separates metadata checks from stored-byte rehashes, and what still needs human review.
By AuditIt Editorial Team · Fact checked
What to know
- A SHA-256 value supports change detection for the specific bytes that were hashed.
- AuditIt’s default public check compares recorded fields; stored-byte rehashes are separate results.
- A hash match cannot decide physical condition, cause, safety, or liability.
A SHA-256 value is a digest computed from a specific set of bytes. The label tells you which hash algorithm was used; it does not tell you what was hashed, which comparison ran, or when it ran. Those details decide how far you can rely on the result.
The US Secure Hash Standard, FIPS 180-4, names SHA-256 and gives it a 256-bit digest size. NIST describes the digest as a way to detect whether a message has changed since the digest was generated. That is a data-integrity question, not a certificate, a safety finding, or a decision about liability.
If you arrived here from an AuditIt result, start with the guide to public report verification. This article focuses on the SHA-256 label inside that result.
Before you rely on a SHA-256 result, ask three questions
Keep the object, the check, and the time together. A bare hash value leaves out the context a reviewer needs.
- What object was named? A PDF, an original photograph, and saved hash metadata are different objects. A result for one does not cover the others.
- Which comparison ran? AuditIt’s default page compares recorded fields. A deep result can re-read stored bytes; every public view does not do that.
- When did it run? A deep result applies to the named object at the time shown. It cannot explain when a physical mark appeared or what happened on site.
This is the practical difference between a useful SHA-256 result and an overclaim. “The stored PDF matched at the time shown” names a check. “The whole record is proven” does not.
What NIST says about SHA-256
FIPS 180-4 says a change to a message will, with very high probability, produce a different digest. The NIST SHA-256 glossary entry uses the same change-detection language. Neither source says a digest identifies the person who changed the bytes, their reason, or the condition of an asset in the yard.
The current NIST landing still presents the August 2015 Final. It also carries a 7 March 2023 planning note saying NIST decided to revise FIPS 180-4, including removing the SHA-1 specification. That note is not a replacement standard, and SHA-256 remains listed in the Final shown on the page.
FIPS 180-4 is a US Federal standard. Non-Federal organizations may adopt it, but citing the standard does not validate AuditIt or turn a hash result into a global inspection rule. The standard itself says conformance does not assure that a particular implementation is secure.
What AuditIt checks by default
AuditIt’s default public Valid result compares recorded verification fields. The exact public copy is:
This report's signed manifest, report hash, PDF hash record, signature/refusal records, and persisted evidence hash metadata match the AuditIt verification record.
That statement is about saved records agreeing. It is not a fresh read of the stored PDF or original photographs.
A deep result answers a narrower byte-level question. When a PDF rehash passes, the page says the stored PDF bytes were re-read and matched the recorded SHA-256 at the time shown. A separate original-media result is required for the photographs. If that result is absent or did not pass for the file in front of you, leave the original-media claim unmade.
For the related wording boundary, see tamper-evident vs tamper-proof. AuditIt uses tamper-evident language because a relevant alteration can become detectable; the record is not locked against every change.
A mismatch starts a review; it does not finish one
NIST IR 8387 is written for evidence-management professionals. It explains that hashes are highly sensitive and that a comparison can fail for reasons that do not change the evidence itself. The report is not an AuditIt procedure, but it illustrates why a mismatch needs investigation rather than an automatic accusation.
Picture a boom lift returning with a scuffed guardrail. A matching recorded hash can show that the saved digest agrees with the verification record. It cannot date the scuff. The reviewer still needs the photographs, notes, timestamps, and any other material in the record.
The same principle applies across AuditIt’s sixteen named industries and general fallback. Templates can be customized; none becomes a universal inspection checklist because it contains a SHA-256 value.
Using a SHA-256 result in a handover
When you pass the result to a colleague, include the named object, the check that ran, and the displayed time. If there is a mismatch, point to that specific row and ask for review. This keeps a technical integrity signal attached to the record it describes.
AuditIt can keep submitted observations, photographs, and verification details together for that review. A default result can show recorded-field matches; a deep result can report a stored-byte comparison only for the object and time shown. AuditIt creates tamper-evident, human-review-ready records. It is not legal certification and does not determine liability.
To start a structured condition record, create an AuditIt account.
Direct answers
Frequently asked questions
What is SHA-256 in an audit record?
SHA-256 is a hash algorithm named in US FIPS 180-4. It turns a specific set of bytes into a 256-bit digest that can be compared with another digest later. The comparison supports change detection; it does not certify the facts described in the record.
Does a matching SHA-256 prove the original photo is unchanged?
Only a passed deep original-media rehash supports that narrow statement for the named file at the displayed time. AuditIt’s default public page compares recorded hash metadata and does not re-read stored photo bytes.
If two SHA-256 values differ, was the file deliberately tampered with?
The mismatch shows that the compared bytes did not produce the same digest. It does not identify a person or motive. NIST IR 8387 also notes, in an evidence-management context, that hash comparisons can fail in ways that do not change the evidence itself.
Can an automated workflow treat a matching hash as a final decision?
A workflow can use the result as one input, provided it keeps the object, check, and time attached. It should route a mismatch for review and must not turn a hash match into a decision about physical condition, cause, safety, or liability.
Is FIPS 180-4 a rule for every rental yard?
FIPS 180-4 is a US Federal standard that non-Federal organizations may adopt. It is not a global rental-yard inspection rule, and citing it does not establish that AuditIt is a validated FIPS implementation.
Has SHA-256 been removed from the Secure Hash Standard?
The current FIPS 180-4 landing still lists the August 2015 Final and a 2023 decision to revise it. The planned change includes removing SHA-1; the page still lists SHA-256 in the current Final.
Sources
- FIPS 180-4, Secure Hash Standard (SHS), National Institute of Standards and Technology
- SHA-256 - Glossary | CSRC, National Institute of Standards and Technology
- NIST IR 8387: Digital Evidence Preservation, National Institute of Standards and Technology
- SHA-256
- hash
- condition records
- public verification
- tamper-evident
