What Auditors Actually Look For in Your Change Management Process
After talking to dozens of IT auditors, we have compiled the specific evidence they look for when evaluating change management controls, and the most common failures they find.
The Auditor's Perspective
Auditors evaluating change management controls are not trying to catch you doing something wrong. They are trying to verify that your documented process is being followed consistently. The gap between what your change management policy says and what actually happens is where findings originate. The most common issue auditors encounter is not missing controls but inconsistent application of controls that nominally exist.
The Five Evidence Elements
Across SOC 2, SOX, and ISO 27001, auditors look for five core elements per change: (1) Authorization - evidence that the change was approved before implementation, typically a ticket or approved request. (2) Design review - evidence that someone other than the author reviewed the technical approach. (3) Testing - evidence that the change was tested before deployment, including test results. (4) Approval - evidence of formal sign-off from an authorized approver. (5) Documentation - a clear record of what was changed and why.
Common Audit Findings
The most frequent change management findings include: changes deployed without documented approval (often emergency fixes), no evidence of peer review for code changes, missing or insufficient testing documentation, changes that cannot be traced to an authorized request, and segregation of duties violations where the same person authored, reviewed, and deployed a change. Each of these findings is preventable with proper evidence capture at the time the change occurs.
What Good Evidence Looks Like
Auditors value evidence that is contemporaneous (created at the time of the activity), specific (clearly tied to a particular change), and verifiable (independently confirmable). A merge commit with linked PR showing description, review comments, CI results, and approval timestamps is stronger evidence than a retroactively created spreadsheet entry. The key principle is that evidence should be a natural byproduct of the development process, not a separate documentation exercise.
Preparing for Your Next Audit
Start by performing a self-assessment: select 10 recent changes at random and attempt to produce all five evidence elements for each. If you cannot, you have identified your gap. Then evaluate whether automated evidence capture can fill those gaps without changing your engineering workflow. The best compliance tools are invisible to developers, capturing evidence from their existing tools (GitHub, Jira, CI/CD) without requiring additional steps.
Ready to automate your change evidence?
Install the GitHub App and start capturing compliance evidence from your first PR merge. Free 14-day trial, no credit card.
Get Started Free