Infrastructure as code as ISO 27001 evidence

Can infrastructure as code and CI pipelines serve as ISO 27001 evidence?

Yes, in most cases. Infrastructure as code and CI pipelines can produce configuration evidence for Annex A control A.8.9 (configuration management) and change evidence for A.8.32 (change management), because every change is recorded, reviewed and traceable to a person and a commit. The certificate itself is different: only an accredited certification body can issue it after an audit, and an implementation partner or your own team can only prepare the systems and records the auditor will sample. Whether the pipeline actually counts as evidence depends on four things. First, scope: the repositories, state files and cluster namespaces must cover the systems inside your ISMS scope, or auditors will ask where the rest of the changes happened. Second, branch protection: the main branch should require a merge request approval from someone other than the author, and direct pushes should be blocked. Third, recorded review: the approval, the diff and the pipeline result should all be attached to the change, not held in chat. Fourth, retention: confirm how long your platform keeps job logs, artifacts and audit events, and set that period against your own record retention rules.

Check these four points in a dry run before the audit. Pick one recent infrastructure change, then ask whether you can show the requester, the reviewer, the scan results and the deployed state without querying anyone's memory. Also confirm your edition. In GitLab Community Edition, SAST runs in every tier and saves its results as a JSON job artifact, but group and project audit events require Premium or Ultimate, and the Free tier records only successful sign-in events. Ask your platform or integration partner to show exactly which events are retained for the period you need, and document the gap if one exists. Records of the change decision belong in your change management procedure, which the pipeline supports but does not replace.

Which evidence each tool produces

Each component in a delivery pipeline records a different slice of how systems were configured and changed. Auditors testing A.8.9 and A.8.32 usually need several of these records together, and none of them alone shows that the whole process operated as designed. Check what each one proves, what it leaves out, and how long your edition keeps it.

IaC state and repository history

Infrastructure as code files in Git show the intended configuration and every approved change to it, with author, reviewer and timestamp on each commit. The state file records what the tooling last applied, which can differ from the repository after manual edits. Compare the two during sampling. Confirm where state is stored, who can read or write it, and whether state history is retained beyond the current version.

Protected branch rules

Protected branch settings show whether changes to production branches needed a review by a second person before merge. The rule configuration is evidence of design, not of operation, so pair it with merge request records that show the approval actually happened. Ask whether administrators can bypass the rule, and whether that bypass is logged and reviewed.

Pipeline job logs and JSON reports

GitLab SAST runs open-source analyzers on each commit and saves detected vulnerabilities as a downloadable JSON report job artifact, available in every tier. This shows that scanning ran for a given change and what it found at that point. It does not show how each finding was triaged or fixed. Confirm artifact expiry settings, because artifacts that expire before your audit window closes leave gaps.

Kyverno policy reports

PolicyReport and ClusterPolicyReport resources record pass, fail, warn, skip or error results for each resource matching a policy, from admission events and periodic background scans. They describe current cluster state only. Kyverno policy reports do not keep a history of blocked admission requests, so pair them with Kubernetes Events or metrics if you need proof of what was rejected and when.

Trivy findings for images, IaC and secrets

Trivy scans container images and Kubernetes clusters for known vulnerabilities, infrastructure as code misconfigurations, secrets and software licenses. Its output is a point-in-time result tied to the scanner's vulnerability database on the day it ran. Keep the scan output with the image digest or commit it covered, record the database version used, and confirm how the team tracks accepted risk for findings that stay open.

GitLab audit events

Group and project audit events record administrative actions such as permission and setting changes, which auditors use to test who changed the pipeline and access controls. On GitLab Community Edition, these events need Premium or Ultimate, while the Free tier records only successful sign-in events. Confirm the edition licensed for your environment and export or retain its logs elsewhere, since the Free tier cannot evidence configuration changes.

Where free editions leave gaps in the audit trail

Free and community editions often record less than an assessor will ask for, and the gaps tend to sit in the admission and access history rather than in the configuration itself. In a Kubernetes setup using Kyverno, the PolicyReport and ClusterPolicyReport resources show current state only: they record pass, fail, warn, skip or error results for resources that exist now, from admission events and background scans. They do not keep a history of blocked admission requests. Those denials need to be captured from Kubernetes Events or from metrics, and the cluster's event retention is usually shorter than an audit period. Confirm how long your cluster keeps events, then forward them to a central store before they expire.

GitLab Community Edition has a similar limit on the access side. Group and project audit events require Premium or Ultimate, and the Free tier records only successful sign-in events. A reviewer asking who changed a protected branch setting, who approved a merge or who removed a member will find no record in the free tier. Before you rely on a free edition for change management evidence under A.8.32, check the current feature matrix with GitLab and your reseller or licence owner, because tier features change between releases. Where the matrix does not cover what you need, export pipeline logs, CI job artifacts and repository event data to a central log store that your team controls, and document that export as a control with its own owner and review.

Who owns the controls, who builds the evidence, who issues the certificate

The organization owns the ISMS. Under ISO 27001, the policies, the risk decisions, the approval of changes and the management review of how configuration and change are controlled all belong to the organization's own leadership and staff. A partner can draft material, but it cannot accept risk on your behalf or sign off your changes, and an auditor will ask who did.

Policies and standards: Approve the configuration baseline, the change management procedure and the rules for which changes need a second reviewer.
Risk decisions: Decide which exceptions to admission policies are acceptable, how long they last and who approves them.
Change approval: Name the people who approve production changes and keep that approval in the pipeline or ticketing system.
Review: Hold periodic reviews of policy reports, failed scans and configuration drift, and record the outcome.
Ownership of accounts: Keep administrative access to the repositories, cluster and pipeline runners under your control.

Before engaging anyone, confirm internally who will sign the Statement of Applicability entries for A.8.9 and A.8.32 and who will review the evidence each quarter.

How the evidence gets built before the audit

The sequence below turns infrastructure as code, admission policies and pipeline records into a dated, scoped evidence pack that an independent certification body can sample. Each step produces an artifact that the next step depends on.

Confirm scope and in-scope systems
The organization, with its ISMS owner and platform engineers, lists the systems, clusters, repositories and cloud accounts that fall within the ISMS scope. Each entry names the owning team and the environment it runs in. The output is a scope register that matches the scope statement and the Statement of Applicability. The step is done when every repository that can change production configuration appears on the register, and anything left out has a documented reason.
Define the change procedure and approvers
The change owner writes the procedure that governs changes to infrastructure, pipelines and applications, covering who may propose a change, who approves it, what testing is required and how emergency changes are handled. This procedure is the written basis for A.8.32 Change management. The output is an approved procedure with named approver roles, and the check is that each approver role maps to an actual team member with the right access.
Enable branch protection and pipeline gates
Platform engineers configure protected branches so that production-bound code cannot be merged without review, and add pipeline stages for static analysis, secret detection, container and IaC scanning, and policy checks. Results are stored as job artifacts. The output is a configuration export showing protection rules and required stages. The check is a test merge that the pipeline blocks when a required stage fails or an approval is missing.
Deploy admission policies in audit mode first
Engineers install admission policies in the cluster in audit mode, so that they report violations without blocking deployments. Kyverno writes PolicyReport and ClusterPolicyReport resources for each matching resource, both from admission events and from periodic background scans. The output is a set of reports that show the current compliance state of existing workloads. Once the team has reviewed and fixed findings, it switches the policies to enforce mode and records the change through the same procedure.
Collect and retain records
The team sets up retention for pipeline artifacts, IaC plans, merge request approvals, policy reports and cloud audit logs. Because policy reports show only current resources, the team also captures Kubernetes Events or metrics for blocked admission requests, and confirms what the free edition of its tooling records. The output is a documented retention schedule and a storage location with access controls. The check is that a sample change can be traced from request to approval to deployment to policy result.
Run an internal review sample
The ISMS owner or an internal reviewer who did not build the controls selects a sample of recent changes and traces each one through the evidence chain. They look for missing approvals, policy exceptions without records and gaps in the logs. Findings go into the corrective action process. The output is a written review record with the sample, the results and the actions raised. The step is done when the sample passes or every exception has an owner and a fix date.
Hand the evidence pack to the certification body
The organization assembles the evidence pack with the scope register, change procedure, pipeline and policy configurations, retention schedule, sample traces and review record, then provides it to the certification body on request. The implementation partner may prepare the pack, but the certification body alone assesses it and issues any certificate. The output is an indexed evidence pack that the auditor can navigate without help. Ask the certification body which formats and access methods it accepts before the audit begins.

Why IaC evidence fails an assessment sample

An assessor samples changes, scan results and log entries, then asks whether each one traces back to an approved request and an owner. The pitfalls below are the places where pipeline-based evidence usually breaks under that sampling, and each one has a concrete fix the organization can put in place before the audit.

Manual changes outside the pipeline

Engineers who log into a console or run kubectl apply directly change production without any pipeline record, so the Git history no longer matches the running state. Under A.8.9 the documented configuration and the live configuration must agree. Check this by comparing cluster or cloud state with the repository on a sample of resources, and restrict write access to the pipeline service account so that direct edits are the exception that gets detected. Drift found in a sample is a finding, even when the change itself was harmless.

Emergency changes with no record

Urgent fixes during an incident often skip review and are recorded only in a chat thread or a ticket written days later. Under A.8.32, changes to production systems should follow change management procedures, and an emergency path is still a path that needs a record. Define an expedited change type with required fields (who approved, what changed, when it was reverted or regularized), and reconcile emergency commits against incident tickets at a set interval.

Scan findings with no triage record

Trivy and GitLab SAST can report hundreds of findings on a single build, and a pipeline that is green while findings sit unreviewed does not show that risk was managed. Assessors look for who triaged each finding, the decision (fix, accept, false positive), and the expiry date on any accepted exception. Keep the JSON report artifacts, record exceptions in the risk register with an owner and review date, and confirm that the pipeline blocks or flags new high-severity findings.

Policy reports mistaken for a block log

Kyverno policy reports show the current pass, fail, warn, skip or error result for each resource, and they reflect cluster state rather than history. They do not record every admission request that was denied, so an organization that presents them as proof of blocked deployments will be asked for the missing history. Capture admission events and Kubernetes Events in a retained log store, and confirm with your Kyverno version's documentation which events are retained and for how long.

Free-tier audit gaps

The free tier of GitLab Community Edition records only successful sign-in events, while group and project audit events require a paid tier. An assessor who asks who changed a protected branch setting or removed a member may find no answer in the free edition. Before committing to a tooling design, confirm in the current edition documentation which events are recorded, and export or forward the events your evidence depends on to storage the organization controls.

Secrets and drift not monitored

Credentials committed to a repository or drift accumulating between scheduled reviews are often discovered only when someone looks. Pipeline secret detection and periodic configuration scans need an owner, a schedule, and a record of what was found and fixed, because the control asks that configurations are monitored and reviewed, not merely defined. Schedule the scans, route alerts to a named role, and keep the dated output as the evidence of review.

Questions teams ask about IaC evidence for ISO 27001

Does an infrastructure as code repository alone satisfy A.8.32 change management?

No. A repository is one input. A.8.32 asks that changes to information processing facilities and information systems follow change management procedures, so an auditor will look for a documented procedure, a record of each change, evidence of who approved it and when, and a way to show that the change in production matches what was approved. Git history shows what was committed, but it does not show whether the change was reviewed, tested or authorized under your procedure. Pair the repository with merge requests that require a second reviewer, protected branches that block direct pushes to the main branch, pipeline logs for each deployment, and a link from each change to a ticket or record. Confirm with your assessor how they want approvals recorded before you design the workflow.

Do we need a paid GitLab tier to keep change evidence?

It depends on which evidence you need. GitLab Community Edition is MIT licensed, and its SAST analyzers run in the pipeline on each commit and save results as a JSON job artifact in every tier, which supports scanning evidence. Group and project audit events, however, require Premium or Ultimate, and the Free tier records only successful sign-in events. If your procedure depends on a record of who changed project settings, approved access or altered protections, the free tier may leave a gap. Check the current edition documentation in the GitLab repository and document the gap as a risk if you choose not to pay. Ask the assessor whether they accept an alternative log, such as a centralized audit trail from your identity provider or Git server.

Is Kyverno enough to prove configuration management?

Kyverno covers part of A.8.9 configuration management, but not all of it. Its PolicyReport and ClusterPolicyReport resources record pass, fail, warn, skip or error results for resources, from admission events and periodic background scans, so they show the current state of your cluster against your rules. They do not keep a history of blocked admission requests. For that you need Kubernetes Events or metrics, retained in a log store. Configuration management also asks for established, documented, monitored and reviewed configurations across hardware, software, services and networks, and Kubernetes policy only reaches the cluster layer. Your infrastructure as code, cloud configuration baselines and review records must cover the rest.

How far back must change and configuration records go?

ISO/IEC 27001 does not give a fixed retention period in the requirement text itself, so the answer comes from your own documented procedure and what the assessor samples. Auditors usually select changes across the audit period and ask for the record behind each one, so your retention must cover at least the full certification cycle, which for ISO/IEC 17021-1 runs three years with an audit in every calendar year. Ask your certification body how many months of history they expect to sample, and confirm your log retention settings in the tools you use. Free editions may keep less history than you need, so test retention before the audit window opens.

Can our own engineers prepare this evidence without outside help?

Often yes, if the team has time and clear ownership. The work is mostly configuration: standard pipelines, merge request approvals, policy rules, scan jobs, retention settings and a written change procedure. Engineers who already run infrastructure as code can usually build it, but the effort grows with the number of repositories, clusters and environments. The main risk is not technical. Teams often skip the link between a change record and the approval, or they leave no written procedure for the auditor to test. Ask your internal team to produce a sample evidence pack for one change before you commit to the full scope. An implementation partner can prepare systems and evidence, but the organization still owns the controls.

What does outside help cover, and what stays with us?

A fixed-scope implementation partner can configure the pipelines, policies, scanners and log retention, document how they work, and prepare the evidence the auditor will sample. What stays with the organization includes the change procedure, the decision to approve or reject a change, the risk owners, the access rules and every control statement in the Statement of Applicability. The auditor, not the partner, tests the controls and issues the certificate, so an implementation partner cannot promise an outcome. Before signing, ask for a written scope that lists the repositories, clusters, environments, tools and evidence types included, and the items the client must provide. Costs follow from that scope, so request a quote tied to the list.

Do we need separate tools to scan containers and dependencies?

Not necessarily, but you need evidence that scanning happens on each change and that findings are tracked. Trivy, an Apache-2.0 licensed scanner, checks container images and Kubernetes clusters for known vulnerabilities, infrastructure as code misconfigurations, secrets and licenses, so it can run in the same pipeline as your infrastructure code checks. GitLab SAST and container scanning can produce job artifacts that record each run. Scanning alone does not satisfy the control. You still need a rule for which findings block a release, a way to record accepted risk, and proof that the scan ran on the commit that was deployed. Confirm the scanning scope and output format with your assessor before you rely on a single tool.

When to bring in an implementation partner for pipeline evidence

Bring in an implementation partner when the pipeline exists but the evidence it produces is not yet mapped to the controls an assessor will test. A working GitLab pipeline with Trivy and Kyverno running is not, by itself, evidence for A.8.9 Configuration management or A.8.32 Change management. The gap is usually in the mapping: which pipeline job, which merge request approval, which policy report and which protected branch setting answers which part of the control, and where the record is kept for the full audit period. If your team cannot name those links for each control, outside help is worth scoping. The same applies when several clusters or repositories enforce different Kyverno policies or different protected branch rules, because an assessor will expect one documented standard applied consistently across them.

A written scope should name the repositories, clusters, pipelines and Kyverno policy sets in scope, the Annex A controls the evidence must support, and the evidence owner for each. Ask the partner to state what it will configure, what it will document, and what remains your responsibility, including approvals, access reviews and the retention of GitLab audit events. Confirm the tier you are on before work starts: the GitLab Community Edition audit event limits mean that some change records may have to come from a higher tier or from logs you export and retain yourself. Also ask how Kyverno blocked admission requests will be captured, since policy reports show only current resources. Agree deliverables and acceptance criteria in writing, and confirm the fee structure and timeline from the quote rather than from assumptions.

Keep the certification body independent of the work. The partner prepares configurations, policies and evidence, but only an accredited certification body issues the certificate, and the partner should not perform the internal audit or the certification audit for the same scope. Check that the same firm is not both designing the evidence and judging it, and ask the certification body whether its rules on consultancy involvement have been met. Confirm the current certification body accreditation through the IAF CertSearch database that ISO points to, and record in the statement of work that the partner has no role in the certification decision.

How DeployOpen prepares pipeline evidence for your audit

DeployOpen plans, implements and hardens self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, including the infrastructure as code and CI pipelines that produce configuration and change evidence. We prepare that evidence for your assessment, but your organization owns its controls and only an independent auditor or certification body issues a certificate.

How we scope

Engagements are fixed-scope, with the pipelines, repositories, clusters and environments in scope agreed in writing before work starts.
We confirm which A.8.9 and A.8.32 processes your organization already runs, so the written scope matches your actual change practice.
The scope names who approves changes, who owns each policy and which audit log retention periods your organization must meet.

How we build

We set up infrastructure as code repositories with protected branches, required reviews and pipeline stages for scanning and policy checks.
We configure admission policies such as Kyverno to report pass, fail, warn and error results against Kubernetes resources as configured.
We wire container, IaC and dependency scanning, such as Trivy, into pipelines and test that the resulting reports are stored as build artifacts.

How we hand over

You receive documented pipeline designs, policy definitions, scan configurations and a record of the tests we ran against them.
Handover includes a short guide showing your assessor where each change record, approval and scan report is kept and how to retrieve it.
We document the limits of free editions, including where audit events or admission block history need Kubernetes Events, metrics or a paid tier.

How we support

Ongoing support, upgrades and continuous testing of the pipelines are available as a retainer, scoped separately from the initial work.
We can help your team prepare evidence packs for an upcoming surveillance or recertification audit, within the written scope.
Questions from your auditor about evidence are answered by your team with our support, since the auditor alone decides what is sufficient.

Using infrastructure as code and CI pipelines as ISO 27001 evidence