Most audit packs are built after the fact.
That is the weakness.
The screenshot is taken after the audit request arrives. The log export is prepared after the system has moved on. The control owner writes how the process is supposed to work.
The report becomes coherent.
Coherence is not proof.
Compliance evidence automation is not template filling. It means collecting bounded observations from source systems, preserving provenance, validating integrity, evaluating policy, and producing a reviewable evidence package.
A clean audit pack can still be built on weak evidence.
That is the problem compliance automation must solve first.
The report is too late
A report is downstream.
It cannot rescue stale evidence.
It cannot repair a missing timestamp.
It cannot establish which source system was observed.
It cannot prove that the evidence remained unchanged after collection.
Most automation starts at the wrong layer.
It generates summaries.
It fills templates.
It writes control narratives.
That saves labour.
It does not harden evidence.
Evidence needs provenance
Data alone is not evidence.
An evidence object should tell us:
what was observed;
when it was observed;
where it came from;
what collected it;
whether it changed after collection;
and which policy result was produced from it.
Without that structure, the reviewer may have data but not a defensible audit trail.
A file name is not provenance.
A screenshot without capture context is not a complete evidence object.
A manually entered timestamp is only an assertion unless the collection process supports it.
An evidence object becomes replayable only when its identity, provenance, integrity state, and policy context can be reconstructed later.
For the replay test, see Can Your Audit Evidence Survive Replay?.
Collection is not correction
The collector should not fix the system.
If collection changes the target, the failed state may disappear before it is recorded.
Operations may like that.
Audit should not.
Read-only collection is not a tooling preference.
It is restraint.
Pull the configuration.
Timestamp it.
Seal it.
Evaluate it.
Remediate later.
Observation and remediation are different jobs.
Read-only does not prove that collection was complete or correct. It preserves a narrower boundary: the collector is not intended to correct the state it is supposed to observe.
For that boundary, see Read-Only Collection as an Audit Boundary.
Integrity comes before judgment
A hash does not prove compliance.
It does not prove that the collector observed the correct system.
It does not prove that the required scope was complete.
It proves a narrower claim:
The preserved bytes match the bytes that were sealed.
That is useful.
If integrity verification fails, the audit path should stop.
OPA should not evaluate evidence that has already failed its own integrity boundary.
The correct result is not automatically non_compliant.
It is invalid_evidence.
Bad evidence should not produce a clean result.
OPA is not the system
Open Policy Agent is a policy evaluator.
Not a collector.
Not a repair tool.
Not an audit writer.
Its job is narrow: take validated evidence and evaluate whether the observed state satisfies a defined policy condition.
That narrowness is the point.
The collector observes.
The validator checks evidence.
OPA evaluates policy.
The audit narrative explains the result.
Policy should stay deterministic.
Narrative comes later.
TLS shows the boundary
Take an Apache HTTPS service.
The weak audit asks whether HTTPS is enabled.
The stronger audit asks:
when the certificate was observed;
which endpoint was inspected;
when the certificate expires;
which signature algorithm was observed;
whether the evidence was sealed;
and whether it was verified before policy evaluation.
The first approach checks a claim.
The second preserves evidence.
A certificate expiring within 48 hours is not automatically a universal compliance failure.
It becomes a control result only when the applicable policy defines that threshold and the evidence is valid for the intended scope.
The audit narrative should stay tied to that boundary:
Based on verified TLS evidence collected at the recorded time, the observed certificate was within the policy-defined expiry threshold. The defined condition was therefore not satisfied for the evaluated endpoint.
No legal conclusion.
No claim about the entire control environment.
Just evidence, condition, and result.
MAS TRM-inspired means engineering interpretation
MAS TRM is the context here.
It does not prescribe this schema, collector, OPA rule, or evidence pipeline.
MAS TRM-inspired means engineering interpretation.
The engineering task is not to rewrite regulatory language into softer prose.
It is to turn a control expectation into an inspectable evidence structure.
A control expectation needs:
a defined observation;
an evidence schema;
a collector;
a timestamp;
an integrity check;
a policy condition;
and an audit narrative.
The schema is not the control.
The policy result is not the entire audit conclusion.
That is the machine boundary.
The position
Compliance automation is not report automation.
Report automation makes audit packs faster.
Evidence automation makes control claims harder to fake, harder to mutate, and easier to replay.
That is the useful distinction.
Reports persuade.
Evidence survives.
Related Reading
Origin
CodeYourCompliance
Website: https://www.codeyourcompliance.com/
GitHub: https://github.com/codeyourcompliance
Attribution is requested for forks, references, adaptations, and discussions.
Scope Boundary
MAS TRM-inspired means engineering interpretation.
This is not legal, regulatory, audit, certification, compliance, or implementation advice.