Infrastructure as code as SOC 2 evidence

Can infrastructure as code and CI pipelines serve as SOC 2 evidence?

Yes, infrastructure as code and CI pipelines can carry much of the change management and configuration evidence a SOC 2 examination asks for, provided the controls are defined, enforced and logged. The organization owns those controls and proves they operate. The implementation partner can prepare the code, pipelines and records, but only an independent CPA firm issues the report. Whether existing code and pipelines are enough depends on three things: the tooling tier, the cluster and pipeline design, and whether the evidence covers the whole audit period rather than a single snapshot.

The change management side rests on the version-controlled baseline. Under CC8.1, an assessor will look for authorization, testing, approval and implementation of each change, and the strongest evidence is a Git history where merge requests carry reviews, protected branches block direct pushes to production, and each deployment links back to an approved change. Under CC7.1, the configuration standard is the infrastructure code itself, and a drift or scanning job, such as a Trivy misconfiguration scan run in the pipeline, shows that unauthorized changes are detected. Ask your auditor early which of these records they will accept as the change ticket and which they expect to see alongside it.

The gaps tend to appear in the logs. Kyverno policy reports record pass, fail, warn, skip or error results for current resources, and they do not keep a history of blocked admission requests, so the blocked attempts need Kubernetes Events or metrics retained elsewhere. On the GitLab side, the Community Edition's SAST output is saved as a JSON artifact in every tier, but group and project audit events require Premium or Ultimate, and the Free tier records only successful sign-in events. Confirm with your auditor and your tier before you rely on any of these records, and plan an export or retention step that keeps evidence for the full Type 2 period.

Which pipeline and IaC artifacts satisfy change evidence

Change evidence for SOC 2 is a set of records that each prove one part of the change lifecycle. No single artifact proves that a change was authorized, tested and deployed as approved, so the auditor looks at how the records connect. The cards below cover the artifacts most teams already generate and what each one can and cannot show on its own.

Version-controlled infrastructure definitions

Infrastructure as code files kept in a Git repository give a dated, attributed record of the intended baseline configuration. They show what the environment was supposed to look like at each commit, which supports the baseline configuration point of focus under CC8.1. They do not prove that the running environment matches the code, so check for drift detection or a periodic comparison between the repository and live resources. Ask whether manual console changes are blocked or recorded.

Merge requests with recorded approvals

A merge request shows the proposed change, the reviewer who approved it and the time of approval. This is the most direct evidence of authorization before a change reaches production. It does not prove the reviewer checked the right things, so sample reviews for substance, such as comments raised and addressed, and confirm that authors cannot approve their own changes.

Protected branches and enforced merge rules

Protected branches restrict who can push to the main branch and can require approvals and passing checks before a merge. They turn the approval step from a habit into a control. The evidence is the branch protection configuration itself, exported or screenshotted with a date. It does not show whether administrators can bypass the rule, so document who holds that permission and how bypasses are logged.

Pipeline job records and test results

Pipeline runs record which commit was built, which tests and checks ran, and whether they passed. They provide the testing evidence that CC8.1 expects before implementation. A green pipeline proves the checks ran, not that they were sufficient, so confirm which tests are required by the pipeline definition and that failed runs cannot be deployed.

Scan outputs from security tooling

Scan reports for code, dependencies, containers and infrastructure definitions show what was checked and what was found at the time of the change. Saved as job artifacts, they support the vulnerability and misconfiguration monitoring expected under CC7.1. They do not prove that findings were triaged or fixed, so keep the decision record for each finding alongside the scan output.

Deployment logs and admission records

Deployment logs tie a released version to the approved commit and the time it reached production. Kubernetes admission policy reports add a record of whether each resource passed or failed policy. These show what was deployed and when. They do not show who approved the change unless the deployment is linked to the merge request, and policy reports reflect only current resources, so capture blocked requests from events or metrics if the auditor needs them.

How Kyverno and Trivy support CC7.1 configuration standards

CC7.1 asks the organization to define configuration standards for its infrastructure and software, monitor against them, detect changes, identify unknown or unauthorized components and run vulnerability scans. Kyverno and Trivy can produce much of that evidence, but they answer different questions. Kyverno shows whether the resources in a cluster match the policies you wrote. Trivy shows whether images, clusters and infrastructure as code files contain known vulnerabilities or misconfigurations. Before the auditor arrives, decide which policies are your written configuration standard, then map each one to the Kyverno policy or Trivy scan that checks it.

Kyverno writes PolicyReport and ClusterPolicyReport resources that record pass, fail, warn, skip or error results for each matching resource. Results come from two sources: admission events when a resource is created or changed, and periodic background scans of resources already running. Because the report reflects current cluster state, it does not show a history of blocked admission requests or of resources that were fixed and later drifted. For that history, keep Kubernetes Events or metrics, and export the policy reports on a fixed schedule, for example a daily snapshot stored with your change records. Confirm the retention period and export method against your own environment and log storage design.

Trivy scans container images, Kubernetes clusters and infrastructure as code for misconfigurations, along with known vulnerabilities, secrets and licenses. Run it in the CI pipeline on each change to show that the configuration was checked before deployment, and run it on a schedule against running clusters to show current exposure. Save each scan output as a dated artifact and record which rule set and Trivy version were used, since the auditor will ask whether the standard was applied consistently across the period. Agree with your auditor in advance which findings must be fixed and which may be accepted with a documented risk decision.

Where free editions leave audit-log gaps

Free and community editions produce useful change evidence, but some records an assessor may ask for are missing or incomplete. The cards below cover the two gaps this page identifies and the steps that close them, so the evidence trail for CC7.1 and CC8.1 holds up through the observation period.

Kyverno blocked requests have no history

Kyverno policy reports record the current result for each matching resource, drawn from admission events and periodic background scans. They do not keep a history of admission requests that were blocked. If your evidence for CC8.1 depends on showing that out-of-policy changes were rejected, the report alone will not show it. Plan to capture Kubernetes Events or metrics for denied requests and export them on a schedule, so the record survives beyond the cluster's event retention window. Confirm the retention period of your cluster's events with your platform team.

Kubernetes events need external retention

Kubernetes Events are short-lived by design, so a blocked admission that happened last quarter may no longer be visible when the auditor samples it. Route admission-related events and Kyverno metrics to a log store you control, such as a self-hosted log platform in your own account, and keep the time, requester, resource and policy name for each denial. Review the export job itself as a control, since a silent failure in the exporter becomes a gap in your evidence.

GitLab Free records only sign-ins

The GitLab Community Edition Free tier records successful sign-in events. Group and project audit events, which show who changed settings such as protected branches, members and CI configuration, require Premium or Ultimate. Without them, a change to a deployment pipeline or a branch protection rule may leave no attributable record. Confirm the current tier feature list with GitLab before you rely on it, since tier boundaries change.

Closing the audit-event gap

You have two practical routes. The first is to move to a paid tier that provides group and project audit events, then export them on a recurring schedule. The second is to keep the free edition and record changes to protected branches, pipeline definitions and project membership through repository hooks or a separate change ticket that links each merge to an approved request. Whichever route you choose, document it in the control description so the auditor understands where the evidence comes from.

SAST reports as pipeline artifacts

GitLab SAST runs open-source analyzers on each commit and saves detected vulnerabilities as a downloadable JSON job artifact in every tier. That artifact is durable evidence of scanning, but artifacts expire according to the retention setting in your project. Set the retention period deliberately, or copy the reports to your evidence store at the end of each pipeline, so the scan record for a sampled change still exists when fieldwork begins.

Confirm tier features before the period

Tier features, log retention and export options can change between releases, so the gap analysis should be dated and repeated. Before the observation period starts, check each tool's current feature list against the controls you cite, record the version you tested, and ask the auditor which evidence they will accept. A short written gap register that names each missing record, its compensating source and its owner is the document most likely to save time at fieldwork.

How to build the evidence trail before the audit window

This sequence turns infrastructure changes, configuration rules and pipeline scans into dated records that a CPA can sample across the observation period. Each step names the artifact the auditor will request, so gaps appear while they are still cheap to fix.

Define baseline configuration standards
Write the configuration standard for each system class in scope, such as cluster nodes, container images, cloud accounts and CI runners, and store it in version control as code. The security or platform lead approves each baseline, and the approval is recorded in the repository history. This standard supports the defined configuration expectations in CC7.1 and the baseline configuration point of focus under CC8.1. Done means every in-scope system points to a versioned, approved baseline that an auditor can read without asking the team for context.
Enable branch protection and required approvals
Configure protected branches so that no change reaches the production branch without a reviewed merge request, and require approval from someone other than the author. Platform engineering owns the settings, and the security lead confirms the rules match the change policy. Export the protection settings and keep screenshots or API output with the date. Done means a test push to the protected branch is rejected and the approval record is visible on the merge request.
Add scanning to every pipeline
Add static analysis, secret detection, infrastructure as code scanning and container image scanning to the CI pipeline so they run on each commit. Open-source analyzers such as Trivy can cover misconfigurations and vulnerabilities, and the pipeline should save each scan result as a job artifact. Confirm which scanners your GitLab edition supports before you rely on them. Done means a sample commit produces a stored report with findings or a clean result, and the team has documented how findings are triaged.
Configure admission policies in audit mode first
Deploy Kubernetes admission policies, for example with Kyverno, in audit mode so they record pass and fail results without blocking deployments. Review the policy reports for a period, fix the workloads that fail, and document any accepted exceptions with an owner and a reason. Only then switch selected policies to enforce. Done means the policy reports show the expected results for current resources and the exception register explains every remaining failure.
Set up log retention for admission and access events
Policy reports reflect current cluster state and do not keep a history of blocked admission requests, so route Kubernetes events, admission audit logs and CI and source control audit events to a central store with a retention period set by policy. Confirm which audit events your platform edition records, since some free tiers only keep sign-in events. Done means a blocked deployment from a test run can be found in the retained logs with its timestamp, actor and reason.
Run a sample change through the full path
Choose one representative change, such as a configuration update to a cluster policy, and push it through the entire path: request, merge request, review, pipeline scans, approval, deployment and post-deployment check. Keep every artifact that the change produced in one folder or ticket. This is the walkthrough the auditor will ask you to perform, so run it as a rehearsal. Done means the change can be traced from its ticket to the deployed resource, and any gap found is logged and fixed before the observation period starts.

Who owns the change controls and who prepares the evidence

The organization owns its controls. Under CC8.1, management must decide how changes to infrastructure, software, data and procedures are authorized and approved, and those decisions cannot be delegated to a tool or a partner. The infrastructure code, pipeline configuration and policies are assets the organization runs after the project ends, so its own staff must understand and maintain them.

Approval rules: Define who may approve a change to production, which changes are standard, and which need a second reviewer.
Pipeline ownership: Assign named owners for the CI/CD configuration, branch protection settings and the admission policies in the cluster.
Exception sign-off: Record who approves emergency changes and how they are reviewed afterward.
Operating evidence: Review pipeline results and policy reports on a set schedule and keep the records.
Ongoing maintenance: Keep baselines current when the platform, base images or Terraform modules change.

Confirm with your own team that every approver named in the change policy has the access and authority the policy gives them.

What usually breaks the evidence trail

Infrastructure as code and CI pipelines produce strong change evidence only when every change passes through them. The pitfalls below are the gaps auditors most often find when they sample changes and ask for proof of authorization, testing and approval.

Manual changes outside code

A console edit, an ad hoc kubectl apply or a hotfix applied directly on a host creates a running state that no commit, review or pipeline run describes. Under CC8.1, the auditor will compare the live configuration against the baseline in code and ask who authorized each difference. Avoidance step: restrict write access to production accounts and clusters to the pipeline's deployment identity, then run a scheduled drift check (for example, a plan that should show no changes) and keep its output as evidence.

Shared credentials that bypass approval

When engineers reuse a shared deployment key or an administrator account, the pipeline's approval gate can be skipped and the change log shows a name that does not match the person who made the change. Auditors test whether the person who deployed was the person who was authorized to do so. Avoidance step: issue individual identities through the identity provider, remove standing administrator rights, and confirm that protected branches and deployment environments require a named approver who is not the author.

Policies left in audit mode

Admission policies set to report rather than enforce let non-compliant workloads reach the cluster while still producing a failure entry in the report. The record then shows a control that existed on paper but did not stop anything. Avoidance step: decide per policy which rules must enforce before go-live, move those to enforce mode, and keep audit mode only for rules that are being evaluated, with a dated owner and exit date for each.

Emergency changes with no after-the-fact record

Incidents often force a fix straight into production. If the emergency path skips the pipeline and no ticket is raised until days later, the change has no authorization, testing or approval trail, and CC8.1 expects changes made in emergencies to be handled. Avoidance step: define an emergency procedure that still creates a ticket at the time of the change, requires a post-change review by someone outside the responder group, and back-fills the code change into the repository within a set window.

Scan results not retained

Pipeline scanners such as GitLab SAST write their findings to a job artifact that expires under the project's retention settings. If results are not exported and stored with the change record, the team cannot show what was detected and how it was resolved for a past period. Avoidance step: set artifact retention to cover the full observation period or export each report to an evidence store, and link each finding to the merge request that fixed it.

Log retention shorter than the observation period

A Type 2 examination samples evidence across a whole observation period, so logs that roll off after a shorter window leave gaps the auditor cannot fill. Free editions can also limit what is recorded: GitLab Community Edition's Free tier records only successful sign-in events, not group or project audit events. Avoidance step: confirm the audit event coverage of each tool in your edition, forward logs to storage that outlasts the observation period, and test a retrieval of a sample from the start of the period before fieldwork.

Questions buyers ask about IaC evidence for SOC 2

Does infrastructure as code replace the change ticket in a SOC 2 audit?

No. Infrastructure as code does not replace the change record, it supplies much of its content. CC8.1 expects each change to be authorized, designed, tested, approved and implemented, and the auditor will look for proof of each step. A merged pull request with a linked ticket, a recorded approval and a pipeline run that deployed the change can together show the full path. The organization still owns the decision to allow the change. Confirm with your auditor which of your existing records they will accept as the authorization step, because some firms want approval captured before deployment and others accept a protected-branch review as long as it is recorded.

Will the auditor accept CI pipeline logs as change evidence?

Often yes, but only when the logs show more than a green checkmark. An auditor will usually want to see who initiated the change, what was changed, which tests ran, who approved it and when it was deployed, and will want to confirm that the pipeline cannot be bypassed for production. Protected branches that require review, and deployment jobs that run only from approved refs, help make that case. Pipeline logs also expire under retention settings, so confirm the retention period with your auditor and export records for the audit period. Ask the auditor which log fields they need before you design the pipeline output.

What must our own team do when IaC is used as evidence?

The team owns the controls, the approvals and the records. An implementation partner can help build the repositories, pipelines and policy checks, but the organization must decide who may approve production changes, define the configuration standards that the code encodes, and run reviews of drift and exceptions. Someone internal must also be able to explain the process to the auditor and show it working during the observation period. Expect ongoing work for pipeline maintenance, access to the repositories and reviewing scan results. Only an independent CPA firm issues the SOC 2 report.

How do free editions limit what the SOC 2 report can show?

Free editions can produce useful scan and pipeline evidence but can leave audit-trail gaps. For example, GitLab Community Edition runs open-source SAST analyzers in the pipeline on each commit and saves the results as a downloadable JSON job artifact, which works across tiers. However, group and project audit events require Premium or Ultimate, and the Free tier records only successful sign-in events. That means failed sign-ins and permission changes may need another log source. Kyverno policy reports reflect current resource state and do not keep a history of blocked admission requests, so you would need Kubernetes Events or metrics for that. Check the edition limits with each vendor before you commit to a design.

How much effort depends on how mature our pipelines already are?

Maturity is the largest driver of effort. A team that already runs versioned infrastructure code, branch protection, automated tests and deployment from pipelines mostly needs to document, export and map its records to the control matrix. A team that deploys by hand will need to introduce version control, a review step, baseline configurations and a single deployment path before any evidence is meaningful. Other drivers include the number of environments, the number of teams with production access, and how much of the infrastructure is still managed outside code. Ask any consultant or partner to assess your current state in writing before agreeing a fixed scope.

Can a Type 1 report rely on configuration snapshots from infrastructure code?

A Type 1 report covers the suitability of control design as of a specific date, so a snapshot of the current configuration can show that a baseline existed and what it contained on that date. It does not show that the control operated over time. Snapshots taken from infrastructure code at the report date, together with the documented standards they implement, are a sensible basis for a Type 1. The Type 2 report, which covers operating effectiveness over a period, needs records of changes and checks across that period. Confirm with your CPA firm whether they accept a point-in-time export for the Type 1 and what they will request for the Type 2.

Which configuration controls does CC7.1 expect IaC to support?

CC7.1 covers defined configuration standards, monitoring of infrastructure and software, change-detection mechanisms, detection of unknown or unauthorized components and vulnerability scanning. Infrastructure code can define the standard, and drift detection or scheduled scans can show whether production still matches it. Trivy, which is Apache-2.0 licensed, scans container images, Kubernetes clusters and infrastructure code for misconfigurations and known vulnerabilities, and its output can be stored as evidence. Scan results are only useful if someone reviews them and tracks findings to closure, so define that owner and cadence before the observation period begins.

How DeployOpen prepares infrastructure evidence for your audit

DeployOpen works on the change and configuration side of your SOC 2 in writing before any pipeline or cluster policy is changed. The scoping step names which changes fall under CC8.1, which configuration standards sit under CC7.1, which repositories, branches, pipelines and clusters are in the system boundary, and who approves each kind of change. That document becomes the reference the auditor tests against, so it is agreed with your engineering and compliance leads before implementation starts. Your organization decides what its controls are and whether they meet its commitments. DeployOpen's role is to prepare the systems and evidence those controls depend on.

On your infrastructure, the implementation typically covers protected branches and required review settings in your Git platform, CI jobs that run open-source scanners such as Trivy against infrastructure as code and container images, and Kyverno policies that record pass, fail, warn and error results in PolicyReport resources. The log gaps need the most attention. Kyverno policy reports reflect current resources only, and blocked admission requests must be captured through Kubernetes Events or metrics. Free editions may also limit audit events, so confirm which audit events your edition records before you rely on them. DeployOpen can export those records to storage you control, but whether a given edition supports a given event is a question for the vendor and your own test environment.

DeployOpen then hands over the documentation the auditor will ask for: the scoping document, pipeline and policy configurations under version control, a runbook for how evidence is exported and retained, and a register of known gaps and compensating steps. Ask your auditor early which samples they will pull, the period they will cover and whether they accept system-generated exports as evidence. The independent CPA firm alone decides whether the controls operated effectively and issues the report. Confirm the scope, deliverables and timeline in a written agreement before work starts.

Using infrastructure as code and CI pipelines as SOC 2 evidence