Why Audit Evidence Goes Stale
Freshness as a missing metric in MAS TRM-inspired compliance automation
An access review export was collected two weeks before the audit pack was finalized.
The export is real.
The timestamp is real.
The file hash still verifies.
But the system changed after collection.
The evidence is intact.
The conclusion is not.
That is the freshness problem.
A verified hash does not make stale evidence current.
Evidence can be true and stale at the same time
Compliance teams often treat evidence as a static artifact.
A screenshot was captured.
A report was exported.
A log bundle was saved.
A file hash was recorded.
That may prove something useful.
It does not prove the evidence still supports the conclusion being made today.
Integrity asks whether the evidence changed after collection.
Freshness asks whether the evidence is still recent enough to support the current claim.
Those are different questions.
A stale evidence object can still pass integrity verification.
That is the trap.
Freshness is an evidence property
Compliance evidence freshness is the condition that an evidence object remains recent enough, within its expected validity window, to support the compliance conclusion being drawn from it.
Freshness is not decoration.
It is not a report date.
It is not the date the auditor opened the folder.
It belongs inside the evidence object.
A minimum freshness record should preserve:
evidence_freshness:
collected_at:
valid_until:
freshness_window_seconds:
freshness_status: fresh | stale | expired | unknownThe collection timestamp tells us when the evidence was observed.
The validity window tells us how long that evidence can reasonably support the claim.
The freshness status tells us whether downstream evaluation should proceed.
Without this, the report can quietly reuse old evidence as if it were still current.
Integrity is not freshness
A hash can prove that an evidence object has not changed.
It cannot prove that the system has not changed.
A TLS certificate export can be hashed.
A firewall rule export can be hashed.
An access review file can be hashed.
A cloud configuration snapshot can be hashed.
If the source system changes after collection, the hash still verifies.
The evidence object is stable.
The world it describes may not be.
This is the boundary:
integrity = did the evidence object change after collection?
freshness = can this evidence still support the current conclusion?
Both are needed.
One does not replace the other.
Why stale evidence should not become pass or fail
A stale evidence object should not silently produce a clean control result.
It should not be converted into pass.
It should not be converted into fail.
The correct outcome is a freshness classification.
For example:
verified evidence + expired freshness window = stale_evidence
That is not the same as non-compliance.
It means the evidence can no longer safely support the current conclusion.
The control may be working.
The control may have failed.
The evidence is no longer strong enough to decide.
That distinction matters.
Automation should preserve it.
The evidence quality gate
Policy evaluation should not begin with the control.
It should begin with the evidence.
The pipeline should first ask:
Is the evidence intact?
Is the evidence source clear?
Is the collector identified?
Is the collection time preserved?
Is the evidence fresh enough?
Only then should the system evaluate the control expectation.
A simple evidence quality gate looks like this:
evidence object
-> integrity verification
-> freshness classification
-> derived facts
-> policy evaluation
-> audit narrative
If freshness fails, downstream evaluation should stop or explicitly carry the stale evidence status.
The report should not hide the freshness failure.
A stale evidence example
In the CodeYourCompliance evidence validation pipeline, the sample stale evidence object uses a TLS certificate evidence record.
The evidence was collected on July 1.
It was evaluated on July 7.
Its declared freshness window was 24 hours.
The integrity status is still verified.
The freshness status is stale.
The policy result is not pass or fail.
It is:
{
"input_status": "verified_but_stale_evidence",
"result": "stale_evidence"
}
That is the correct boundary.
The evidence object survived integrity verification.
It did not survive freshness evaluation.
What the audit narrative should say
A weak audit narrative says:
TLS evidence reviewed. No issue noted.
A better audit narrative says:
TLS certificate evidence was collected and integrity verification passed. However, the evidence was evaluated after its declared freshness window expired. The evidence should not be used to support a current compliance conclusion without recollection or updated source evidence.
That is not legal interpretation.
That is evidence discipline.
The narrative should explain what the evidence can still support.
It should also explain what it can no longer support.
MAS TRM-inspired framing
MAS TRM-inspired does not mean MAS TRM prescribes a freshness field.
It does not mean a specific JSON structure, Rego policy, hash algorithm, or evidence pipeline is required.
The framing is narrower.
If a compliance conclusion depends on technical evidence, the evidence should be recent enough to support that conclusion.
That is an engineering interpretation.
It separates the control claim from the proof material behind it.
Freshness changes the report boundary
Reports often collapse time.
They present collected evidence, reviewer notes, control statements, and conclusions inside one document.
That can make old evidence look current.
A freshness field forces the report to show the time boundary.
It asks:
When was this evidence collected?
How long was it valid for this claim?
When was the conclusion made?
Did the evidence remain fresh at conclusion time?
If the answer is no, the report should say so.
The evidence may still be useful background.
It should not be treated as current proof.
Technical companion
A stale evidence example and a narrow OPA/Rego freshness policy demo are available in the CodeYourCompliance evidence-validation-pipeline repository.
Stale evidence example:
Evidence freshness policy demo:
These examples do not implement a complete evidence integrity model.
They show one boundary:
verified evidence can still be stale evidence
Boundary
This material is for evidence structuring and technical review preparation.
It does not provide legal, regulatory, audit, certification, compliance, procurement, or implementation advice.
The goal is not to prove MAS TRM compliance.
The goal is to make the evidence freshness boundary visible before stale evidence becomes a clean report conclusion.
Origin
CodeYourCompliance
Website: https://www.codeyourcompliance.com/
GitHub: https://github.com/codeyourcompliance
Attribution is requested for forks, references, adaptations, and discussions.
Related reading
Can Your Audit Evidence Survive Replay?
What a MAS TRM Checklist Cannot Prove
A Screenshot Is a Supporting Artifact, Not a Proof Object