The question is not whether a control was documented. The question is whether the underlying system state can be verified, trusted, and replayed after the fact.

That is where CodeYourCompliance starts.

Compliance is not documentation. It is evidence that can be replayed.

Most compliance work still starts with documents.

Screenshots. Spreadsheets. Static reports. Manual attestations. These artifacts are useful, but they are often asked to do something they were not designed to do: prove that a technical control was actually true at a specific point in time.

In this article, compliance automation means converting regulatory expectations, such as MAS TRM[1]-inspired security controls, into verifiable system evidence that can be collected, timestamped, checked, evaluated, and replayed.

Documentation can describe a control.

It cannot, by itself, prove that the system was in a specific security state when evidence was collected.

That distinction matters.

The Evidence Problem

A static audit report usually tells us the conclusion.

It may say that TLS was enabled, that a certificate was present, or that a configuration was reviewed. But it often does not preserve the evidence chain behind that conclusion.

The harder questions are usually left open.

Was the evidence collected without changing the system?

Was it bound to a timestamp?

Was it modified after collection?

Was the policy decision based on verified facts?

Could another reviewer replay the same path and reach the same conclusion?

These questions matter in the context of MAS TRM expectations because technology risk management depends on control assurance, not just control description.

A report is useful.

But a report is not the same thing as verifiable compliance evidence.

A Minimal Evidence Pipeline

The first CodeYourCompliance experiment uses a deliberately narrow scenario.

A Rocky Linux 10 host acts as the Ansible controller. A Rocky Linux 9 host runs Apache HTTPD with TLS enabled. The Apache TLS certificate is intentionally configured to approach expiry within a short window, such as 48 hours.

The goal is not to prove full MAS TRM compliance.

The goal is to show how a technical audit conclusion can be traced back to timestamped, integrity-checked system evidence.

The pipeline is intentionally small:

1. Collect system state in read-only mode.

2. Package evidence with an ISO 8601 timestamp.

3. Generate a SHA256 integrity hash.

4. Verify the evidence before analysis.

5. Derive TLS facts such as certificate expiry and signature algorithm.

6. Evaluate verified facts using OPA/Rego[2] policy logic.

7. Generate a MAS TRM-aligned audit narrative.

The important design choice is this:

Policy evaluation should not run on unverified evidence.

If the evidence hash does not match, the result should not be pass or fail. The correct result is invalid_evidence.

That boundary separates weak automation from defensible audit automation.

What This Experiment Shows

This experiment demonstrates a minimal replayable evidence path.

The audit conclusion is not based on a screenshot, a manual statement, or declared configuration alone.

It is based on collected system evidence, sealed at a point in time, verified for integrity, normalized into facts, evaluated by policy, and translated into an audit narrative.

For example:

Based on cryptographically verified TLS certificate evidence collected at a specific time, the HTTPS service was operating with a certificate approaching expiry within the defined threshold. This condition weakens assurance over the TLS certificate lifecycle and does not align with MAS TRM-inspired expectations for maintaining strong cryptographic controls.

That sentence is not just prose.

It has a chain behind it:

system state -> timestamped evidence -> integrity verification -> derived facts -> policy evaluation -> audit narrative

That is the difference between a report and a replayable audit path.

Scope and Limitations

This is not legal, regulatory, audit, or certification advice.

It does not claim MAS TRM compliance.

It does not replace auditors, risk owners, governance teams, or formal regulatory interpretation.

It also does not claim that SHA256 alone is enough for enterprise-grade evidence assurance. Production systems may require signed manifests, trusted timestamping, immutable storage, key management, approval workflows, and independent validation.

The point is narrower:

Where technical evidence exists, compliance conclusions should be replayable.

Companion Repository

The public companion repository for this article is available here:

https://github.com/codeyourcompliance/evidence-validation-pipeline

It contains the sample evidence structure, sample report, and future reference implementation assets for the evidence validation pipeline.

Substack explains the problem language. GitHub stores the public technical artifacts.

Closing

Compliance automation should not begin with the report.

It should begin with the evidence.

If the evidence cannot be collected, verified, evaluated, and replayed, then the conclusion may still be useful as documentation. But it is weaker as compliance evidence.

That is the line CodeYourCompliance will keep exploring:

from static documentation
to replayable evidence
to machine-evaluable compliance.

[1] MAS TRM refers to the Monetary Authority of Singapore Technology Risk Management Guidelines.
Official MAS page: https://www.mas.gov.sg/regulation/guidelines/technology-risk-management-guidelines

[2] OPA/Rego refers to Open Policy Agent and its policy language Rego.
Official OPA documentation: https://www.openpolicyagent.org/docs