Why compliance evidence should come from live infrastructure state

A screenshot proves that something was true at the moment the screenshot was taken. That is all it proves. It says nothing about the hour before, and nothing about the eleven months that follow.

An auditor is not asking whether your bucket was private on the day you took the picture. They are asking whether the control was operating — continuously, over the audit period. Those are two different claims, and the second one cannot be assembled from a folder of the first.

What your current compliance tool actually does

The compliance platforms most companies own — Vanta, Drata, Secureframe — connect to your cloud through an integration and poll it. Every few hours, or every day, the integration wakes up, asks a handful of questions, and records a pass or a fail against a control.

This is genuinely useful, and it is not what it appears to be. A green tick on a dashboard means “the last time we looked, this was fine.” It does not mean the control held between the looks. If someone opened a security group during an incident at 02:00 and closed it at 05:00, the poller may never have seen it. The dashboard stays green. Nobody lied. The evidence is simply not there.

Worse, the record produced is a summary. It says control A.8.2 passed. It does not say which of your four hundred IAM principals were checked, what their attached policies were, or when. Hand that to an assessor who does not already trust you, and you have handed them your own conclusion rather than the facts that support it.

The alternative: read the state, keep the reading

The other approach is to read the configuration of every individual resource, evaluate it against a rule, and keep the reading — not the conclusion. One row per control, per resource, per check, with a timestamp.

This makes the record much larger and much more boring, which is the point. Instead of “access control: pass,” you have the raw response the AWS API gave when it was asked about a specific IAM user, the specific rule that was applied to it, and the moment it happened. An assessor can disagree with your rule. They cannot disagree with the reading.

Three properties that make a reading defensible

It has to be reproducible. The same configuration, run through the same rule, must produce the same answer every time. That rules out putting a language model anywhere in the evidence path. A model that is right 98% of the time has, in a compliance file, introduced a 2% chance that the thing you are attesting to is a hallucination. There is no acceptable error rate for a statement you sign. All 133of Enforcer's checks are plain declarative rules for exactly this reason.

It has to be tamper-evident. Evidence that can be quietly edited after the fact is not evidence, it is a note. Each record is hashed when it is written and the hash is never recomputed — a hash that heals itself proves nothing. The export bundles those hashes into a manifest so the whole pack can be checked by anyone, with nothing but a shell.

It has to be resource-level.“Encryption is enabled” is a claim about a company. “This bucket, with this ARN, had this encryption configuration at this timestamp” is a fact about a thing. Only the second one survives a hostile reading, and hostile readings are what an audit is.

The honest part

Everything above is an argument, not a finding. No auditor has reviewed this evidence format — not one, as of today. It is entirely possible that a lead assessor reads a control matrix and says the thing they actually need is something else, and that our reasoning here is elegant and beside the point.

That would be worth knowing. It would be worth knowing now, before a customer stakes a certification on it. So the format is published, the sample pack is downloadable, and the hashes are yours to check. If you audit against ISO 27001 and you think this is wrong, we would like thirty minutes of your time, and we will publish what you tell us either way.