CloudFormation, Bicep, and Terraform all generate evidence about what they deployed, when, and on whose behalf. The evidence is not the same shape across the three frameworks, the audit consumers are not the same audience, and the supply chain question — which artefact was deployed, who attested to it, and what changed — is answered differently by each. The 2026 audit landscape has gotten stricter about provenance, and the IaC layer is where most of the evidence lives.
I have done audit-evidence work for SOC 2, FedRAMP, and PCI-DSS engagements over the past two years, in environments that ran one or more of the three IaC frameworks. The evidence patterns that survive auditor scrutiny are consistent. The patterns that do not survive have a common failure mode: the evidence is recorded but cannot be joined to the artefact, or the artefact is signed but the deploy event cannot be tied to the signature.
What does the auditor actually want?
A chain. The auditor wants to see, for every production deploy: the source commit, the build that produced the artefact, the signature on the artefact, the policy decision that admitted the artefact, and the deploy event that placed it into production. Each link in the chain is a piece of evidence in a different log, and the chain is what proves the deploy was authorized.
The IaC layer's role in the chain is the deploy event. The IaC framework records what was deployed, by whom, with what parameters, and at what time. A well-instrumented IaC pipeline also records the artefact reference (the image digest, the package hash, the lambda code SHA), which is the join key that ties the deploy event to the upstream evidence.
The mistake most environments make is recording the deploy event without the artefact reference. The CloudFormation stack update log says "stack updated" but does not say "with image X at digest Y." The audit chain has a missing link, and the auditor flags it. The fix is to make the artefact reference an explicit input to the IaC, recorded in both the IaC source and the deploy log.
How do I get audit-ready evidence from CloudFormation?
CloudFormation produces stack events that record every resource creation, update, and deletion. The events are stored in CloudFormation for thirty days, and longer in CloudTrail. The event includes the stack name, the resource type, the change type, and the principal that initiated it. The artefact reference is recorded if the IaC author included it as a parameter or a resource property.
The pattern that produces audit-ready evidence is to include every artefact reference as an explicit stack parameter, with the values recorded in both the stack template and the deploy log. The parameter value is typically the image digest, the lambda code S3 URL with version, or the package URL with checksum. Recording the value as a parameter makes it visible in every CloudFormation event for the stack.
The signing of the CloudFormation template itself is the next layer. AWS supports signed templates via the registry's resource type publisher feature, with the consumer verifying the signature at deploy time. For one-off templates, the source repository's commit signature serves the same purpose when the deploy pipeline verifies commits. The CloudTrail log is the long-term evidence store and the system of record for the auditor; its integrity (log file signing, MFA-delete on the bucket, retention policy) is its own audit dimension.
How do I get audit-ready evidence from Bicep?
Bicep deploys produce activity log entries with the same structure as any Azure resource operation. The log entry includes the resource ID, the operation, the principal, the timestamp, and a correlation ID that ties the deploy event to the deployment record in the resource group's deployment history. The artefact reference is recorded if the Bicep author included it as a parameter.
The pattern that produces audit-ready evidence is the same as on AWS: every artefact reference is an explicit parameter, the parameter values are recorded in both the Bicep source and the deployment record, and the deployment record is retained beyond the resource group's default retention. Azure's deployment history defaults to keeping the last eight hundred deployments per resource group, which is fine for short-term audit but inadequate for compliance frameworks that require multi-year evidence.
The longer-term evidence store on Azure is the activity log archived to a Log Analytics workspace or an Event Hub, with a retention policy that matches the compliance framework. The activity log is the auditor's primary evidence source for Azure, and the retention policy is a compliance question, not just a cost question.
The signing of the Bicep template uses the new Azure DevOps approval check pattern. The Bicep template lives in a repo with branch protection, the deploy pipeline extends a required template that runs the signature verification, and the deploy is approved by an identity that has the right role assignment. The chain is: signed commit → required template → approval check → deploy event, with the deploy event recording the artefact reference.
How do I get audit-ready evidence from Terraform?
Terraform's evidence story is more flexible and less prescribed than the cloud-native frameworks. The flexibility lets the customer build a precise audit story. The lack of prescription means many customers build no audit story at all, and the evidence is missing when the auditor asks.
The pattern that works is Terraform Cloud, Terraform Enterprise, or an equivalent Open Tofu workflow with a remote state backend, a structured run log, and a policy enforcement layer. The remote state backend records every state change with a version, a timestamp, and the principal. The run log records every plan and apply with the inputs, the outputs, and the diff. The policy layer enforces the supply chain controls — signed modules, pinned versions, attested artefacts.
Module signing is the part of the chain that gets skipped most often. Public-registry modules should be pinned to a specific version with checksum verification. Private-registry modules should be signed by the publishing pipeline and verified by the consuming pipeline; the verification lives in the wrapper that runs terraform plan and terraform apply. The artefact reference is typically a variable injected from the pipeline at apply time, with the value recorded in the run log and the resulting state file, so the previous state, the planned diff, and the new state collectively prove what changed.
How do I unify the three frameworks for a multi-cloud audit?
The unification happens above the IaC layer, in the audit log normalization. The CloudFormation event, the Azure activity log entry, and the Terraform run log all describe the same kind of fact — a deploy event with an artefact reference, a principal, and a timestamp. The normalization step produces a common format with five fields: deploy ID, artefact reference, principal, timestamp, and outcome. The join to upstream evidence is on the artefact reference, and the auditor's query "show me the deploy chain for this artefact" returns the same shape regardless of framework.
Drift between the IaC source and the deployed state is its own evidence dimension. CloudFormation drift detection, Bicep what-if comparisons, and Terraform plan against current state all surface drift, and a deployment that has drifted has either been edited out-of-band or modified by a system the IaC does not know about — either way the auditor wants to know.
How Safeguard Helps
Safeguard ingests CloudFormation, Bicep, and Terraform deploy events alongside the upstream build, attestation, and source commit evidence, and joins the records into a unified audit chain. The chain is queryable per artefact, per deploy, per principal, or per time window, with the response shape consistent regardless of which IaC framework or cloud the deploy used.
Griffin AI generates the parameter conventions, signing configurations, and audit log retention rules that produce audit-ready evidence from each framework, then opens pull requests against the customer's IaC repos to roll the conventions out. The PR-driven workflow makes the rollout tractable in environments with hundreds of stacks, deployments, and Terraform workspaces.
Safeguard's SBOM module attaches in-toto attestations to every artefact the IaC deploys, with the attestation joined to the deploy event by the artefact reference. The TPRM module tracks the trust state of every external module the IaC consumes, and the policy gate module integrates with the IaC pipelines so a deploy can be blocked from a Safeguard policy decision rather than a hand-coded check.
For audit and compliance teams, Safeguard's evidence module produces auditor-ready reports per framework, per cloud, and per control, with the underlying chain queryable for every assertion. The continuous evidence collection is the difference between scrambling at audit time and having the chain ready when the auditor asks for it. The unified format across CloudFormation, Bicep, and Terraform is the difference between three audit answers and one.