Most cloud security is a claim: a slide that says "we're secure," a checkbox on a questionnaire, a vendor's word. Cloud Evidence Engineering is the practice of replacing those claims with artifacts — logs, configurations, hashes, timestamps — that can be independently verified by anyone who asks.
Four stages carry a claim from "we think we're secure" to "here is the artifact that proves it." Skip a stage and the chain breaks — the claim reverts to an assertion.
Pull the raw artifact directly from the source of truth — the cloud API, the tenant, the log store. Not a summary of it.
→Timestamp and hash the artifact at collection so it cannot be quietly altered between capture and review.
→Map the artifact against a stated control or standard, and record exactly where it passes, fails, or partially satisfies it.
→Deliver the finding alongside the artifact that produced it, so the reader can check the work instead of trusting it blindly.
Every finding traces back to the exact system, export, and moment it came from — never a secondhand summary.
Evidence is fixed the instant it's collected. If it can be edited after the fact, it's not evidence — it's a draft.
A third party, given the same artifact, should be able to reach the same conclusion without taking anyone's word for it.
Posture drifts constantly. Evidence collected once a year describes a moment that's already gone.
Cloud Evidence Engineering was named and formalized by Paul Turner to describe a practice he saw missing from most cloud security work: the habit of treating proof as optional. The discipline exists so that "secure" stops being a claim you take on faith and becomes a conclusion you can check yourself.
Paul Turner — Originator, Cloud Evidence EngineeringMore case studies, standards, and worked examples of evidence-based cloud assessment are being added as the discipline develops.