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.
| Question | Evidence 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.