Skip to content

BlogDeployment & releases

Release evidence: what auditors ask for and how to have it ready

The change-management evidence auditors expect for software releases, how to collect it as a by-product of shipping, and how to answer the question “what changed and who approved it” in minutes.

Abstract illustration of a ledger of release records with approval marks.

Key takeaways

  • Evidence requests follow the change lifecycle: request, review, approval, test, deploy, trace.
  • Separation of duties matters: the approver should not be the author.
  • Collect evidence as a by-product of releasing, not as a project before the audit.
  • Be able to answer “what changed, when, by whom, approved by whom” for any production state.

Audit season usually starts with a spreadsheet: a sample of production changes and a request for the evidence behind each one. Teams that ship through a controlled path answer in an afternoon. Teams that ship through a mix of pipelines, consoles and chat messages spend weeks reconstructing history. The difference is not how careful the engineers are; it is whether the evidence was captured when the work happened.

What auditors usually ask for

Frameworks phrase these differently, but the lifecycle is the same across common standards for change management and information security.

QuestionEvidence that answers it
Was the change requested and tracked?Ticket or change record linked to the code change
Was it reviewed by someone other than the author?Review record with reviewer identity and timestamp
Was it approved before deployment?Approval record tied to the exact version deployed
Was it tested?Test results attached to the version, not just a green badge
Was it deployed through a controlled path?Deployment log showing who, when, where and which version
Can production be traced back to the change?Running version mapped to the change, release and approval
Were emergency changes handled and reviewed after?Record of the change and a retrospective approval

Why reconstruction fails

Evidence assembled after the fact has gaps: the approval was a thumbs-up in a chat thread, the migration was run from a laptop, the console change has no author. Each gap becomes a finding or a compensating-control conversation. The gaps are not negligence. They are what happens when the fast path and the recorded path are different.

Collect evidence as a by-product

  • Make the release plan the record: scope, order, environments and the approver captured when the plan is reviewed.
  • Attach gate results, test outcomes and health checks to the release automatically.
  • Deploy only through the path that records; make the recorded path the fastest path, including for emergencies.
  • Keep a current map from each environment’s running state to the release that produced it.
  • Export the record in a form an auditor can read without a tour of your tooling.

The question to be able to answer

For any service in any environment, at any point in time: what version is running, which change produced it, who reviewed and approved it, and what checks passed before it went out. If that answer takes minutes, audits are routine. If it takes a week, the problem is the process, not the audit.

Dorvi records this as it ships: the reviewed plan, the approvals, the gate results and the resulting state of each environment, so the evidence exists before anyone asks for it.

Enterprise operations

Dorvi

Review every change with its context, ship services and migrations as one release, and keep the evidence.

Explore Dorvi

Questions

Before you ask.

What is change management evidence?

Records showing that a production change was requested, reviewed, approved, tested and deployed through a controlled path, and that the running state can be traced back to the change.

Does an automated pipeline count as approval?

A pipeline run shows the change was deployed, not that it was approved. Approval needs an identifiable person, separate from the author, recorded against the version that shipped.

How should emergency changes be handled for audit?

Through the same recorded path, with the review and approval captured as soon as practical afterwards. The record should show it was an emergency and who reviewed it after.