CloudTrail is not evidence: why operational logs and integrity proof are different categories

What operational logs are designed for

CloudTrail, Stackdriver, and Azure Monitor were built to answer questions like: which API call did our service make at 03:14 UTC, what was the response, and which IAM principal initiated it. The job is operational visibility — debugging, alerting, capacity planning, security investigation. They are excellent tools for those jobs.

The design constraints that make them excellent for operations also make them inappropriate for evidence. Operational logs are designed to be retained for a window, rotated out, replayed, indexed, queried, and occasionally redacted. None of those operations are problems for the operational job. All of them are problems for the evidence job.

Three structural differences that matter at audit time

When an auditor, regulator, or opposing counsel challenges a record, the conversation moves from operational visibility to forensic defensibility. At that point three structural differences between operational logs and integrity evidence become decisive:

• Same trust domain — your CloudTrail logs are written, retained, and read by accounts inside your AWS organization. The audit log of the audit log lives in the same place. A determined insider with sufficient privileges can mutate the trail and mutate the trail of mutations. Evidence requires a trust boundary outside the system that produced the data.
• Mutation-friendly by policy — log retention windows expire records by design. Lifecycle policies move records to cold storage and eventually delete them. These are features for operations and bugs for evidence. A record you cannot produce on demand at audit time is not evidence; it is a former log.
• No third-party verification path — when you hand a CloudTrail export to an auditor, the auditor has to trust that the export is faithful to the original. There is no cryptographic primitive that lets a regulator verify the export against an immutable reference without your cooperation. Operational logs are statements; evidence is independently verifiable claims.

What changes when integrity is anchored externally

External anchoring — what Certyo does on Polygon — is not a replacement for CloudTrail. It is a different artifact that addresses the three structural gaps above. Records are hashed, accumulated, batched, and the Merkle root of each batch is written to a public chain. Three properties follow from that design:

First, the trust boundary moves outside your account: the on-chain Merkle root cannot be modified by anyone, including the team that operates Certyo. Second, the anchor is not subject to retention policy: it persists indefinitely as a property of the chain, not a property of your subscription. Third, verification does not require your participation: a regulator with the original record and the on-chain reference can independently confirm the record was anchored at the original timestamp.

Where the two artifacts complement each other

The right mental model is not CloudTrail-or-Certyo. It is CloudTrail-and-Certyo, with each artifact doing its own job. The operational pipeline keeps doing what it does well; the evidence pipeline runs alongside, anchoring the records that need to survive audit, dispute, or litigation:

At audit time, CloudTrail answers "what happened operationally" and the integrity anchor answers "and the records that resulted from those operations are unchanged." The two artifacts answer different questions and the answers compose. An auditor who sees CloudTrail alone has a story; an auditor who sees CloudTrail plus an anchored record has a story plus a verifiable claim.

Three buyer scenarios where the distinction is decisive

If the difference between operational logs and evidence sounds academic, it tends to become urgent in three specific scenarios. These are the scenarios where the CloudTrail-is-enough position fails in the field:

• Insider-threat investigations — When a regulator or insurer is investigating possible insider tampering, logs that live inside the same trust domain as the suspected actor cannot be used to disprove the tampering. The investigator needs an artifact that the actor demonstrably could not have modified. CloudTrail does not meet that bar; an external anchor does.
• Multi-year disputes — When a dispute about a record from three years ago surfaces today, the question is whether the record can be produced in its original form. CloudTrail retention may have expired the entry. The integrity anchor on a public chain does not have a retention window. Records you can hash today against the original anchor are still verifiable.
• Cross-vendor audits — When an auditor needs to verify a record produced by your service against records from a partner or counterparty, the auditor cannot ask both organizations to share their CloudTrail. They can ask both to share the anchored hash and verify against the same on-chain reference. Cross-vendor audit is structurally easier when the verification primitive is independent of any vendor.

What to do when the objection comes up in a sales call

The right response to "we already use CloudTrail" is not to argue that CloudTrail is bad. It is excellent at what it does. The right response is to ask which of the three structural gaps the buyer would accept in the worst-case scenario: a determined insider mutating the audit log, a retention policy expiring a disputed record, an auditor unable to verify without your cooperation. If the answer is none, CloudTrail alone is not the right tool for that part of the workload. For how Certyo runs alongside existing log infrastructure, see /en/about. For the verification primitive in detail, see /en/blog/blockchain-without-crypto.

CloudTrail tells you what happened. An integrity anchor lets a third party verify that the record of what happened has not changed. Same data, structurally different trust property. The two artifacts answer different questions and you need both at audit time.