Change authorization and approval

Auditors expect a signed change management policy and an approver authority matrix that names who may approve which types of change, for which applications and environments. The matrix should show business owners approving changes that affect financial logic or reporting, and IT approvers approving technical risk. Auditors check that the approvers named in the matrix were in role during the audit period and that the signatures and version dates are recorded. Keep the policy under version control, review it at least annually, and retain each approved version. Between audits, confirm that the matrix matches current staff and access roles, because an approver who has left or changed duties is a common finding. Ask your team to confirm the review cadence in your own change policy, since no external standard fixes it.

A change ticket passes when it shows the request, a business approval, an IT approval and timestamps that place each step before deployment. Auditors trace a sampled change from the deployment back to the ticket and check that the description states what changed, why and which system was affected. The business approval should come from someone authorized in the matrix, and the IT approval should occur before the change reaches production. Ticket fields that are editable after approval, or approvals recorded in a comment without a named approver, weaken the evidence. Tools such as GLPI, which follows ITIL-based change practices, or Zammad, a ticketing system, can hold this record, but your team should confirm how each tool logs approval history and whether that history can be altered.

Auditors look for a traceable link between the approved ticket and the deployment that put the change into production. The usual link is a change identifier carried in the commit message, merge request, pipeline run or release record, so the reviewer can follow one identifier from approval to deployment. Auditors then check that the deployed code or configuration matches the approved change and that no additional changes were included. If the link is manual, such as a spreadsheet cross-reference, expect more sampling and more questions. Keep deployment logs with timestamps and the identity of the person or service account that executed them. Confirm with your engineering leads that every production deployment path, including scripts run by operators, writes to the same record.

Auditors want configuration evidence showing that only approved roles can push or merge to production branches and that direct pushes are blocked. In GitLab Community Edition, protected branches let maintainers restrict which roles can push or merge, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. Export or capture these settings, and retain dated copies, because the auditor tests the configuration as it existed during the period, not as it stands today. Monthly exports of the protected branch settings, deployment environment approval rules and runner permissions help show the control operated throughout the year. Semgrep Community Edition can run in CI/CD pipelines to scan code, which supports review but is not itself an approval gate, so describe its role accurately. Confirm the exact settings your platform version supports before relying on them.

A population report lists every change to in-scope applications, interfaces, databases and infrastructure over the audit period. The auditor needs it to select a sample and to confirm the sample is complete, because a sample drawn from an incomplete list proves little. The report should be generated from the system of record, such as the ticketing or deployment system, and carry a date, filter criteria and a count. Auditors often re-perform the filter to check completeness, so document the query logic. Before each sample request, reconcile the population against deployment logs to catch changes that bypassed the ticket process. Ask your auditor to confirm the population parameters early, since disputes over completeness are costly late in the cycle.

Emergency and out-of-process changes must be recorded as exceptions, with the reason, the approver, the access used and the time of the fix. Auditors check that the exception was logged promptly, that someone with authority approved it either before or immediately after deployment, and that a retrospective review followed. Each exception should link to a ticket and to the deployment record, and the population report should flag it so it can be sampled separately. Keep a register of all exceptions for the period, even when the count is low, because an absent register invites the question of whether emergency access was used silently. Coordinate this with your emergency change procedure and confirm the review timing your own policy sets.

A periodic review shows that someone independent of the change process compared production deployments with approved tickets and resolved any differences. The review should list the deployments in the period, match each to an approved change, and record each unmatched item with its investigation and outcome. Auditors look for evidence that the reviewer had enough access to see production activity, that the review occurred at a set frequency and that the reviewer signed and dated the result. Many teams run this monthly and retain the reconciliation worksheet with the source extracts. Your team should confirm which reviewer role fits its segregation of duties and whether the review can be performed by a person who did not approve the changes being reviewed.

Setup is mostly a one-time design effort, and running it is a recurring workload that scales with the number of changes. The setup work covers defining which applications, interfaces, databases and infrastructure are in SOX scope, writing a change procedure that names who requests, who approves and what the approval must contain, and configuring a ticket system to enforce that path. The recurring work is the daily handling of requests, approvals and evidence retention. Effort rises with the number of in-scope systems, the volume of changes, the number of approvers involved and how many systems still rely on manual approvals. Ask any provider to break the quote into design, configuration, evidence procedures and ongoing support so you can see which parts recur.

Often yes, if the team has someone who understands both the financial systems and the change process, and the organization is willing to own the design. The organization owns its controls. Outside help is usually most useful for preparing the ticket workflow, mapping in-scope systems, drafting procedures that match how the business actually approves work, and organizing evidence so it is easy to sample. An implementation partner prepares systems and evidence, but only the independent external auditor tests the control and reaches a conclusion. Ask any firm to state in writing which tasks it will perform, which remain with your staff and what documentation you will own at the end.

The timeline depends less on the approval tooling than on how many systems are in scope and how well existing approval practices are documented. Work usually runs longer when approval rules are informal, when several business units approve changes differently, when interfaces and databases are not inventoried, or when the ticket system must be integrated with source control or deployment tools. Each of those adds discovery, decision-making and testing time before the control can run reliably. Before you agree on a schedule, ask the provider to state the assumptions behind it, including the number of systems, the approval owners involved and whether the controls must operate for a full period before the audit.

Business owners need to confirm which changes affect financial results, define who can approve them and state what evidence they need before approving. IT staff need to document the change request, the technical impact, the test results and the deployment record. Both groups need to agree that approvals must happen before deployment, not after. The time commitment is largest during design, when owners review the in-scope list and approval matrix, and smaller during operation, when approvers respond to requests. Confirm with the provider who will act as the business approver, who will sign off on the design and how often those people are expected to attend working sessions.

Emergency changes should follow a defined path, but that path does not have to be identical to the standard one. The usual approach restricts who can make an emergency change, requires an approval from a named owner, usually obtained before the change where practical, and requires a documented review after the fact. The auditor will want to see that the emergency route cannot be used to skip approval entirely. Emergency handling is a sibling topic with its own control design, so ask any provider how it will connect emergency changes to the same ticketing record and whether the review process is written into the procedure.

A self-hosted ticket system can produce acceptable evidence if it records requests, approvals, timestamps and linked changes in a way the auditor can inspect and the organization can protect. GLPI's Assistance module, for example, supports tickets, problems and changes following ITIL practices, with plannings, statistics and a Kanban view, and Zammad is a web-based helpdesk that consolidates requests into one ticket system. Source control can add a second layer. GitLab Community Edition supports protected branches that restrict who can push or merge, block direct pushes and keep force pushes disabled unless explicitly allowed. The tool is not the control. You must confirm that approvals are enforced in the workflow, that records cannot be silently edited and that access to the system is itself controlled. Verify each capability against the version you deploy.

The external auditor needs management to show that the control is designed effectively and operates consistently throughout the period. Under PCAOB AS 2201, operating effectiveness testing combines inquiry of personnel, observation of operations, inspection of documentation and re-performance of the control. In practice, that means a documented change procedure, a complete population of in-scope changes, a ticket for each change showing the request, the approval and the approval date before deployment, and a way to trace those tickets to production. Management should also be ready to explain how the population was generated. Ask providers whether they will prepare evidence packs for sampling and how they will handle changes that bypassed the workflow.