Change and release evidence for ISO 27001 in a CI/CD shop

Change management is one of the controls that catches engineering-led organisations off guard in ISO 27001 Stage 2 audits. Not because their practices are weak - usually the opposite is true. The problem is that the evidence of those practices is spread across Git history, pull request threads, CI logs, and deployment pipelines in a way that is invisible to someone expecting a change log document.

The evidence exists. Surfacing it, connecting it to the right controls, and presenting it in a form an auditor can follow - that is the gap this post addresses.

What ISO 27001 is actually asking for

ISO 27001:2022 Annex A control 8.32 covers change management. The core requirement is that changes to information processing facilities and systems are controlled through a formal process. That process needs to cover planning, testing, authorisation, implementation, and review.

Translated to what an auditor expects to see:

• A change is proposed and its scope is defined before work begins.
• The change is assessed for security impact.
• It is approved by someone with the authority to authorise it.
• The change is tested before it reaches production.
• The deployment to production is recorded.
• There is a way to trace back from the production state to the decision that created it.

Most engineering teams running a mature CI/CD workflow do all of this. The question is whether they do it in a way that is legible as a change management process.

Pull requests as change records

A well-structured pull request in GitHub or GitLab is a change record. It captures the proposed change (the diff), the description of what it does and why, the review and approval (required reviewers plus merge approval), and the timestamp of authorisation. If the branch protection rules require at least one approving review before merge, the merge itself is evidence that the authorisation requirement was met.

What makes a PR a strong change record:

• Title and description that explain the purpose of the change, not just the technical implementation. "Rotates DB credentials after vendor access" tells an auditor what the change was for. "Fix bug" does not.
• Linked issue or ticket connecting the change to a business requirement or security decision.
• Required reviewers configured at the repository level, not optional. An auditor will want to see that the approval requirement is enforced, not just encouraged.
• Review comments where they exist, showing that the approver engaged with the change rather than rubber-stamping it.
• Approval timestamp separate from the merge timestamp, demonstrating that authorisation preceded deployment.

Branch protection settings in GitHub or GitLab serve as the policy-level control here. A screenshot or export of those settings belongs in the ISMS evidence pack alongside the PR records.

CI/CD pipelines as segregation evidence

Segregation of duties in a small engineering team is a genuine challenge. A developer who can both write code and deploy it to production is a segregation risk. CI/CD pipelines are one of the most practical mitigations - they mean that even if a developer has the technical ability to push to production, the standard route to production goes through a pipeline that requires a passing build, passing tests, and a successful merge to the protected branch.

Evidence of this control:

• Pipeline configuration files (.github/workflows/, .gitlab-ci.yml, or equivalent) showing that deployments are triggered by merge to a protected branch, not by manual runs initiated by developers.
• Deployment logs showing the pipeline run that executed the production deployment, with the triggering commit reference.
• Access controls showing that direct push to the protected branch is restricted, forcing the merge-via-PR path.

Together, these create a traceable path: change proposed, change reviewed, change approved by merge, pipeline triggered by the merge, deployment executed by the pipeline, not by a human running a command.

Deploy records and traceability

Every production deployment should be traceable to the change that authorised it. In a CI/CD shop, this traceability exists naturally if the deployment pipeline records the commit SHA and the triggering event. Surfacing it for an auditor means being able to show:

• The production deployment log entry, with timestamp and commit reference.
• The commit that triggered the deployment, and the PR that the commit came from.
• The PR showing the approval and the security-relevant description.

This chain - deployment to commit to PR to approval - is the traceability an auditor is looking for under Annex A 8.32. Most CI/CD tools provide this by default. The gap is usually that no one has thought to include it in the evidence pack.

Deployment records also connect to the change management policy. If the policy states that all changes to production must be authorised before deployment, the CI/CD evidence demonstrates that deployment only occurs after the authorisation event (the merge). The connection between the pipeline configuration and the policy requirement needs to be made explicit in the ISMS, ideally in the change management procedure.

Handling emergency changes in a CI/CD context

Emergency changes are a specific audit focus. An organisation that has a mature standard change process but no defined emergency change process, or one where emergency changes bypass the normal controls without documentation, will receive a finding.

In a CI/CD context, legitimate emergency changes should still follow the PR path where possible - even a short-cycle, expedited review is better than a direct commit to the main branch. Where a direct production action is genuinely unavoidable, the control is documentation after the fact: who made the change, what they changed, what the justification was, and who retrospectively approved it.

A post-incident review note or a retroactive PR created to document an emergency change is acceptable evidence that the emergency was controlled, even if it was not pre-authorised. What is not acceptable is no record at all.

Connecting the tools to the ISMS

The evidence value of PR records, pipeline logs, and branch protection settings is lost if the ISMS does not connect them to the change management process. A change management procedure that describes a manual approval form when the actual process runs through GitHub is worse than no procedure at all - it suggests the ISMS is not reflecting reality.

The change management procedure for a CI/CD organisation should:

• Name the specific tools used (e.g. "all changes to production are managed via GitHub pull requests in the [repository name] repository").
• Reference the branch protection policy as the technical enforcement of the review requirement.
• Define what constitutes an authorised change (e.g. "a PR merged to main with at least one approving review from a designated approver").
• Define how emergency changes are handled.
• State how long deployment records and PR records are retained.

With that procedure in place, the CI/CD artefacts become evidence of the procedure being followed. Without it, they are logs with no ISMS anchor.

What to prepare for Stage 2

Before Stage 2, pull together a change management evidence set that includes:

• The change management procedure that describes the CI/CD process.
• A screenshot or export of the branch protection settings showing review requirements.
• Three to five recent PR examples covering the last operational period, with varied types of changes (feature, security, infrastructure).
• The deployment log entries corresponding to those PRs, showing the commit reference link.
• One documented example of an emergency change if any occurred, with the retrospective approval record.

This set covers the control from policy through to operation through to individual records - the traceability chain an auditor will follow.

Where Kellwick fits

Engineering teams with mature CI/CD practices often have stronger change management evidence than they realise - they just have not mapped it to ISO 27001 controls. Kellwick provides independent advisory for technical organisations preparing for certification, working with the tools and workflows that already exist rather than layering on process for process's sake. Kellwick brings experience reviewing CI/CD-based change management in SaaS environments. Request a readiness assessment to see how your engineering workflow maps to the evidence requirements.