Change management in the IT audit: what the auditor tests and which evidence counts

In almost every IT audit, testing of controls starts with change management. That is no coincidence. An application that calculates interest, enforces an authorisation matrix or generates a report is only reliable if nobody can alter the code, the configuration or the database unnoticed. If they can, the auditor cannot rely on any automated control and has to recalculate by hand everything the application does. Change management is therefore one of the general IT controls: the foundation on which the rest of the audit rests.

This article describes what an auditor wants to see at each step of the change process, how he checks whether the list of changes is complete, how to arrange segregation of duties in a small DevOps team, and the four patterns that produce findings.

Where the requirement sits

The wording differs per framework, the substance does not. In SOC 2 the criterion is CC8.1: the entity authorises, designs, develops or acquires, configures, documents, tests, approves and implements changes to infrastructure, data, software and procedures. In ISO 27001:2022 Annex A 8.32 is the change management control, surrounded by 8.31 (separation of development, test and production environments), 8.29 (security testing in development and acceptance), 8.9 (configuration management) and 8.19 (installation of software on operational systems). Clause 6.3 in the main text concerns changes to the management system itself and is something different. NEN 7510:2024 follows the same numbering. In an ISAE 3402 report the service organisation writes its own control objectives, and an objective about authorised, tested and approved changes is almost never missing. DORA names ICT change management in Article 9 as part of the ICT risk management framework. ITIL 4 has spoken of change enablement since 2019 and distinguishes standard, normal and emergency changes. That threefold split comes back in the audit.

What the auditor wants to see at each step

Registration. Every change to production has a record: a ticket, a pull request, an entry in a change calendar. The record describes what changes and why. The auditor is less concerned with the form than with traceability: can he get from any given deployment back to the request?

Assessment and approval. Someone other than the requester assesses impact and risk and approves before the change goes to production. The word before is the test point. The auditor compares the time of approval with the time of deployment. An approval recorded after deployment is not an approval, however tidy the ticket looks otherwise. A change advisory board is common for large changes but not a requirement; what must be defined is who may approve, and for which type of change.

Testing. The change has been tested in an environment that is not production, against acceptance criteria defined in advance, and the result has been recorded. "Tested, OK" in a ticket with nothing behind it is not evidence. A pipeline run with passing tests, a test report or a screenshot of the acceptance test is.

Deployment. The person who developed the change does not move it to production themselves, or deployment runs through a pipeline that only accepts approved code. A change that puts the service at risk comes with a rollback scenario. The auditor asks not only whether one exists but also whether it was used at the last failed deployment.

Post-implementation verification. After deployment, someone establishes that the change does what was intended and that nothing else came along with it. For infrastructure changes that is often a check of the configuration against the intended state.

Completeness of the list is the real subject

Almost every organisation can produce a stack of approved tickets. The auditor does not start there. He asks for the complete list of everything that went to production in the period, and he wants that list from a source the developers cannot edit themselves: the deployment history of the pipeline, the release log of the platform, the change log of the cloud environment. From that list he draws his sample; for a control that operates daily or more often, in practice frequently in the order of twenty-five changes over a one-year period. For each change he then wants to see the request, the prior approval, the test evidence and the identity of the person who deployed.

The reconciliation between that deployment list and the ticketing system is where it goes wrong. Manual changes, hotfixes, changes made by a supplier and edits made directly in the database appear in the first list and not in the second. Every deployment without a matching ticket is a deviation, and a single unauthorised change to a critical system is enough to assess the control as not effective. How that reconciliation fits into the broader evidence picture is covered in evidence in an IT audit.

So do that comparison yourself, before the auditor arrives. Pull the deployment list, put it next to the tickets and explain every difference. What you cannot explain is exactly what the auditor is going to find.

Segregation of duties in a small DevOps team

The classic requirement is that development, approval and deployment sit with different people. In a team of three that cannot be organised as a fixed division of roles, and it does not have to be. The segregation sits per change: the author of the code does not approve their own pull request, and deployment is done by the pipeline and not by a developer with direct access to production.

The auditor tests that on three points. First, branch protection: mandatory review by at least one other person, no force push to the main branch, and no exemption for administrators. Second, access to production: do developers have accounts that let them deploy or modify the database outside the pipeline? That touches directly on access control, and it is the question on which small teams most often get stuck. Third, operation over time: was branch protection switched on for the entire period, or was it temporarily disabled once for a difficult merge? The audit log of the version control system shows that.

If segregation in advance cannot be achieved completely, a detective control is the alternative. Someone other than the developer periodically reviews the deployment list, establishes that every deployment is an approved change and records that review with date and name. That is a full compensating control, provided the reviews demonstrably took place. A procedure that describes it without a single recorded review does not count.

Infrastructure as code falls under the same rules. An edit to a Terraform file or a Kubernetes manifest is a change to production and goes through the same process as application code. Configuration changes that someone makes directly in the cloud provider's console are the manual changes the reconciliation above is about.

Standard changes and emergency changes

Not every change needs individual approval. A standard change is pre-approved as a type: a routine patch, creating a user according to a fixed procedure, a parameter change within defined limits. The auditor then wants to see the catalogue that states which changes are standard, who approved that catalogue and when it was last reviewed. A catalogue that has grown over the years until almost everything is standard hollows out the control.

Emergency changes break the sequence: deploy first, approve afterwards. That is permitted if the procedure for it exists, retrospective approval takes place within a defined period and the emergency change appears in the same list as all other changes. The auditor also looks at the proportion. An organisation where a third of changes go through the emergency procedure is using the emergency procedure as a detour around the regular process.

Changes at suppliers

For a SaaS application you do not manage the change process yourself. You rely on the provider's assurance report, and the question is whether change management is within the scope of that report and whether any exceptions were reported against it. Read the complementary user entity controls while you are at it. Many providers expect the customer to test new releases in an acceptance environment or to accept them explicitly before they become active. That part of the process is then your control, and the auditor asks you for evidence of it, not the provider.

Four patterns that produce findings

The first pattern is approval after deployment. The ticket is complete, the reviewer has signed off, but the timestamp is after the deployment. This happens mostly in teams that see the process as documentation after the fact rather than as a precondition.

The second is a ticketing system that does not contain everything. Hotfixes go through chat, a supplier adjusts something after a phone call, an administrator changes a setting in the console. The deployment list shows it; the ticketing system does not.

The third is test evidence consisting of a single word. "Tested" in a field, without a result, without criteria, without who did it. In a Type II examination over an observation period of a year, that cannot be repaired afterwards.

The fourth is administrator access that bypasses the pipeline. Branch protection is on, but three people hold a role that lets them push straight to production. The auditor then asks whether that access was used during the period, and the log provides the answer.

What you can do beforehand

Pull the deployment list for the past three months from the pipeline and put it next to the ticketing system. For ten random changes, check whether the approval predates the deployment and whether the test evidence is more than a tick. Look in the version control system to see whether branch protection was changed in that period. Make an inventory of who can reach production outside the pipeline. What comes out of that is the backlog for the months before the audit. How Secure Audit tests change management as part of a broader assessment is described on the IT audit page.