Change testing before production: SOX ITGC evidence

What change testing before production means under SOX

If a change to a financial system reached production without documented testing, your auditor will treat the change as untested until you prove otherwise. Under SOX, change testing before production is the step that shows a modification to an in-scope application, interface, database or configuration was validated before it could affect reported numbers. Neither the SEC nor the PCAOB publishes an IT general control catalog that lists this control by name, so the expectation comes from the general principle in SEC Release 33-8810 that management evaluates the ITGCs needed for its other controls to operate properly and consistently. The practical question for a finance or IT lead is whether you can show, for each sampled change, what was tested, by whom, against which version, and who accepted the result before go-live.

The stakes come from automation. PCAOB AS 2110 lists reliance on systems that process data inaccurately as an IT risk to internal control over financial reporting, and AS 2201 says the evidence needed to verify that an automated control has not changed may depend on the strength of program change controls. If testing is weak, an auditor may not be able to rely on a calculation, matching rule or approval workflow the system performs, and will need to test more manually. Confirm with your auditor early how they plan to rely on automated controls, because that reliance decides how much change testing evidence you must produce.

Two problems make this hard in practice. First, test evidence is usually scattered across email threads, chat messages, spreadsheets and ticket comments, so the test record exists but cannot be traced to a specific change. Second, test scope often does not match the change. A configuration tweak to a tax table may be tested only for the screen that displays it, while the downstream journal entries it drives go untested. Before the audit, pick a sample of recent production changes, then check that each one links to a test plan, test results, the environment used and an approval that predates deployment. Gaps you find now are cheaper to close than gaps an auditor finds in the sample.

Which changes and systems need pre-production testing

Testing before production only matters for the changes that touch financially significant systems. The cards below cover the scoping decisions that determine how much testing is needed, which change types it applies to, and who in the chain of delivery must follow it. Each decision should be written down before the auditor asks for samples.

Applications and interfaces in scope

Start from the financial statement risks, then trace which applications generate, store, calculate or transmit those balances. Interfaces that move data between a subledger and the general ledger, or into a consolidation tool, are often in scope even when the application itself looks peripheral. Ask for a documented list of in-scope systems with the reason each one is included, and confirm that every interface has an owner who can approve changes to it.

Databases and infrastructure layers

A change to an application can be bypassed by a direct change to its database, operating system or virtualization layer. Auditors therefore look at whether those lower layers are in scope, and whether changes to them follow the same test and approval path. Confirm which database instances, servers and cloud accounts host in-scope data, and document who can alter them outside the change process.

Configuration, parameters and data fixes

Configuration changes such as tax rates, approval limits, matching tolerances and posting rules can alter financial results without any code change. Scripted data corrections written directly against production tables carry similar risk. Decide which of these count as changes that need testing, and require the same evidence of test results and sign-off for a data fix as for a code release, with the reason for the correction recorded.

Standard changes, patches and vendor releases

Routine application changes, security patches and vendor upgrades differ in urgency and in how much regression testing they need. Define which change categories are standard, which require full testing, and which may proceed on a vendor's tested release with a documented assessment. Vendor patches are still changes to in-scope systems, so the decision to apply them and the test evidence behind it should be retained.

Internal teams and outsourced developers

Work done by internal developers, contractors, offshore teams and managed service providers all reaches production under the same ITGC. The organization remains responsible for testing and approval even when a provider writes the code. Confirm that contracts require the provider to follow the company's test standards, and that the people who test and approve are independent of the people who build the change.

Third-party software and SaaS vendors

When a financial system is a vendor product or SaaS platform, the company may not control the vendor's development or test process. Its own testing still applies to configuration, integrations and customizations it makes. Ask vendors for their release notes, their own test evidence and any independent reports they provide, then document which parts of testing the company performs itself.

How auditors test pre-production testing and user acceptance

Auditors test whether changes to financially significant systems were tested and accepted by the business before they reached production. They start by selecting a sample of changes that went live during the period under audit. For each sample item they trace the change backward from production to its originating request, then forward to the test evidence, the user acceptance sign-off and the approval that released the change. The question is not whether testing happened in general, but whether this specific change was tested, by the right people, and approved before deployment. A change with a production deployment date earlier than its acceptance sign-off is an exception, however carefully the team worked.

The auditor also reviews the design of the control, not only the operating sample. Under PCAOB AS 2201, testing of operating effectiveness combines inquiry of personnel, observation of operations, inspection of documentation and re-performance of the control. In practice, an auditor will ask the change manager how a test plan is written and who may waive it, watch a change move through the ticketing and deployment workflow, inspect test scripts, defect logs and sign-off records, and sometimes re-perform the release gate by attempting a deployment that lacks an approval. Confirm with your auditor which of these they intend to use for your environment, and ask whether they expect test evidence to be attached to the change ticket itself or retained in a separate repository, because that choice determines how quickly samples can be produced.

How an assessor tests change testing before production

This table sets out what an assessor does for each part of pre-production testing, the evidence they request and the findings they commonly raise. Read each row as a test step: the left column names the step, and the other columns show what good evidence looks like and where organizations usually fall short.

Test area	Assessor approach and evidence requested	Common findings
Design walkthrough	Assessor traces one change from request to production with the owner, and asks how testing is required, who signs off and what blocks a deployment that has not been tested. Evidence includes the written change procedure and the workflow configuration.	Procedure describes testing that the tool does not enforce, so the control exists only on paper.
Sample selection of changes	Assessor takes a sample of production changes from a complete population, such as the change log or deployment records for the period, and checks that the population is complete before selecting items.	Population is built from tickets only, so deployments made outside the ticket system are never tested.
Test script and result inspection	For each sampled change, assessor inspects the test plan or script, the executed results, defects raised and their resolution. Results should be dated before the production deployment date.	Test results are generic or undated, or show failures that were closed without retesting.
User acceptance sign-off	Assessor confirms that the business user responsible for the affected process approved the test outcome, using a named, dated approval that is separate from the requester's own confirmation.	Sign-off is missing, given after go-live, or given by the developer who made the change.
Segregation between tester and developer	Assessor checks that the person who tested a change is not the person who built it, and that test environments are separate from production. Evidence includes role assignments and environment access lists.	Developers hold production deployment rights, or the same individual both codes and approves the test.
Build matches tested version	Assessor compares the identifier of the tested build, such as a release tag, commit hash or artifact checksum, with the version recorded as deployed to production, to confirm nothing changed after testing.	Production runs a build that was never tested, or the deployed version was rebuilt from a different commit.
Emergency fixes	Assessor asks for the population of urgent changes and checks whether each one was approved, followed by retrospective testing and sign-off within the period the organization's procedure sets.	Urgent fixes go live without any test record, and no later review occurs.
Confirm with your own environment	Ask your auditor which sample size and population they will use, and confirm which evidence formats they accept before you change your process.	Evidence exists in several tools that are not linked, which slows the walkthrough and invites exceptions.

How to implement pre-production testing step by step

This sequence turns pre-production testing from an informal habit into a documented control that an auditor can trace, from the list of in-scope change types through to a retrospective check that confirms every production change was tested and approved.

Define in-scope change types and test standards
Start by listing the change types that touch financially significant applications, interfaces, databases, configurations and infrastructure, such as code releases, schema changes, parameter updates and patches. For each type, write a short test standard stating what testing is required, who performs it, which environment it runs in and what counts as a pass. The owner is usually the application owner with IT change management. The output is an approved test standard document, versioned and reviewed each year, that the auditor can read before sampling changes.
Set minimum test requirements by risk tier
Group change types into risk tiers based on their effect on financial reporting, such as the accuracy of calculations, the integrity of data feeds and the reach of the change. Each tier gets minimum requirements, for example unit or regression testing for low-risk changes and documented user acceptance testing with reconciled results for high-risk ones. Confirm the tier criteria with finance and the external auditor before adopting them. The output is a tier matrix that maps each change type to its minimum testing and acceptance evidence.
Assign testers, approvers and sign-off authority
Name who may execute tests, who accepts results for the business and who approves promotion to production, and make sure no one approves a change they built or tested alone. Record the delegation in a sign-off authority list that is reviewed when roles change. Business users should own user acceptance sign-off for changes that alter financial outputs. The output is a sign-off authority matrix that sets out the people, their duties and the segregation between developer, tester and approver.
Link test records to change tickets
Require every change ticket to carry a reference to its test plan, test cases, test results and the named acceptance approval, so that one ticket shows the full path from request to test to approval. The ticketing system should be the system of record, with links or attachments that cannot be edited after approval without an audit trail. Open-source service management tools such as GLPI, which follows ITIL-style change practices, can hold these records, though you should confirm that its change workflow fits your approval steps. The output is a complete change record for each sampled change.
Enforce gates in the delivery pipeline
Configure the source control and deployment pipeline so that code cannot reach production without the required test stages passing and an approval recorded. In GitLab Community Edition, protected branches can restrict which roles may push or merge, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. Static analysis such as Semgrep Community Edition can run in CI/CD to block changes that fail defined rules in supported languages. Test that each gate actually stops a non-compliant change in a dry run. The output is a set of documented gate rules and a test record showing the gates block what they should.
Run a retrospective check against production
Periodically compare what is running in production with the list of approved and tested changes. Use deployment logs, version records or file integrity tools to find any change that has no matching ticket, test evidence or approval, and investigate each exception. Record the comparison and its results so the reconciliation itself is evidence. Findings should feed back into the tier matrix, gate rules and sign-off list. The output is a signed reconciliation log with exceptions, root causes and remediation actions, which auditors can use to judge whether the pre-production control operates as designed.

Which evidence passes an audit and how to keep it current

Auditors test change testing by tracing a sample of production changes back to tested, approved and deployed builds. The six artifacts below form that chain, and each one should be produced as a normal byproduct of the change process rather than assembled before fieldwork.

Change tickets with linked test records

The change ticket is the anchor record. It should name the in-scope application, the requested change, the risk rating and the test records that cover it, with links rather than free-text summaries. Configure the ticket template so it cannot move to deployment until the test fields are filled in. Between audits, run a periodic check that every closed change for a financial system has at least one linked test record.

Test scripts and results

Test scripts show what was checked, and results show what happened when they ran. Keep scripts versioned with the application and record the build or commit tested, the tester and the date. Results that are only screenshots in a shared folder are hard to tie to a specific change. Store them in the ticket system or the repository so the auditor can follow one change from request to result.

User acceptance sign-offs

Business owners of the financial process, not only IT, should approve that the change produces the expected result. A sign-off should name the approver, the test scenario accepted and the date, and be recorded before deployment. Ask whether approvers can approve their own requests, since auditors often look for that segregation. Review the approver list at least once a year against current job roles.

Pipeline logs showing gates

Where changes move through a pipeline, the logs should show that required stages ran and passed before the deployment step. In GitLab, protected branches can block direct pushes and require merges by permitted roles, which gives you a recorded merge path. Confirm that gate settings are not weakened without a change record, and export the protection configuration with each review cycle so the state can be shown later.

Deployment records matching tested builds

The auditor will compare the build deployed to production with the build that was tested. Record the artifact identifier or commit hash in the deployment entry and in the test record, then reconcile the two for a sample of changes. A mismatch means something reached production that no one tested, which is a common cause of exceptions. Automate the comparison where your tooling allows it, and schedule a manual check for systems that cannot export build IDs.

Exception records

Emergency fixes and changes deployed without the full test cycle need their own records, including the reason, the approver, the after-the-fact review and the date the review closed. Track these in a separate queue so they can be counted and reviewed. An exception log that is complete and reviewed on time usually supports the design of the control better than a perfect sample with no exceptions, because it shows management knows where the process bends.

What change testing before production costs

This table breaks down the cost components of testing changes before they reach financially significant systems, who is paid for each one, and whether it is one-time or recurring. Read it to see where spend lands in your own budget and which drivers to raise when you request quotes. No figures are given because none were supplied for this topic, so confirm amounts against your own scope.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Test environments and tooling licenses	Internal platform team, vendors or the implementation partner for setup; license holders for commercial tools	One-time setup, recurring hosting and license renewals	Number of in-scope systems and environments; self-hosted open source such as GitLab Community Edition or Semgrep Community Edition can reduce license spend, but hosting and upkeep remain
Engineering time to build test cases and gates	Internal developers and QA, or a partner under a fixed-scope agreement	One-time for initial cases, recurring as cases change	Count of applications, complexity of financial logic and how often the test suite changes
Business user acceptance time	Finance and process owners, who are internal staff whose time is diverted from their day jobs	Recurring with each release	Change volume, number of reviewers per change and whether acceptance evidence is captured in the ticketing system
Evidence upkeep	Change management and IT operations staff who maintain tickets, test results and approvals	Recurring	Volume of changes sampled by auditors and whether approvals and test results link automatically in one system, such as GLPI or Zammad tickets
External review or testing	Independent security testers or code reviewers, paid per engagement	Recurring if scheduled, one-time for a specific review	Scope of code and systems covered, frequency and whether reviews run inside CI/CD pipelines
Auditor sampling	External auditor, billed through the audit engagement	Recurring each audit cycle	Number of changes in the test population, control reliance and the quality of documentation the auditor can trace
Internal oversight and governance	Internal audit or SOX program management	Recurring	Number of in-scope controls and the frequency of management review of test results

Who owns testing, who can help, and where the auditor stops

Management owns the change testing control, and that ownership cannot be delegated. Your team defines which changes to financially significant systems need testing, sets the minimum test scope for each change type, decides who may approve a change for production, and signs off the test results. Management also has to show that the control operates every period, not only at the moment an audit begins. An outside party can prepare the evidence, but the people who authorize the change must be your employees or accountable managers who understand the financial impact.

Test policy and scope: Define which systems, change categories and risk levels require testing and user acceptance, and document the expected test depth for each.
Sign-off authority: Name the business owners and IT approvers who may accept test results, and keep that list current.
Test execution oversight: Confirm that testers are independent of the developer where practical and that failed tests block promotion.
Operating evidence: Retain test scripts, results, defect records and approval timestamps linked to each change ticket.
Periodic review: Monitor whether the control runs as designed and correct gaps before the fiscal year end.

Confirm that every sign-off in your sample can be traced to a named person with the authority to give it.

Common gaps that fail change testing audits

Auditors rarely fail a change program because testing never happened. They fail it because the evidence cannot be traced, the sign-off is not independent, or the process has an exit that bypasses it. The gaps below are the ones that most often leave an ITGC exception open at year end.

User acceptance agreed by email

Business users often approve a change with a reply email or a chat message, and that message never reaches the change record. The auditor then cannot tell which version was accepted or who had authority to accept it. Close the gap by requiring the acceptance to be recorded as an approval inside the ticket, naming the tester, the test version or build, the date and the scope tested. Check a sample of closed tickets and confirm each one carries that record without relying on a mailbox.

Test evidence not linked to tickets

Test scripts, screenshots and result logs often sit in shared folders or a test tool with no reference to the change request. An auditor tracing a production change back to its testing cannot connect the two. Give every change a unique identifier, and require test results to cite that identifier and the build deployed. Confirm that a reviewer can start from a production deployment record and reach the exact test results in a few steps.

Developers signing off their own tests

When the person who wrote the code also runs the tests, approves the change and deploys it, no independent check exists. Auditors look for a separation between the builder, the tester and the approver for in-scope systems. Where a small team cannot fully separate these roles, document a compensating review by someone outside the build, and check repository permissions so the author cannot merge unreviewed code.

Protected branches missing for code releases

Code that reaches production without a required review or a test gate is a common cause of untested changes. Protected branches in GitLab can restrict which roles may push or merge, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. Confirm that the protection settings are enforced on the branches that feed financial systems, and export them as evidence at the review date.

Emergency changes skipping testing

Urgent fixes to financial systems are sometimes pushed straight to production with testing deferred until later, and no one records that testing was ever done. The control should define what qualifies as an emergency, limit who can invoke it, and require after-the-fact testing and approval within a timeframe the company sets in its policy. Review every emergency change at period end and confirm each one has a completed follow-up record.

Automated scans without recorded results

Teams often run static analysis in a pipeline but never keep the output or show what happened when a finding blocked a release. Semgrep Community Edition can run in CI/CD pipelines to scan repositories continuously across many languages, including Java, Python, TypeScript and Terraform. Keep the scan results per build, record how each finding was resolved or accepted, and link that record to the change ticket so the scan counts as testing evidence rather than an unexplained log.

Which open-source tools produce change testing evidence

Can GLPI Assistance hold change records and approvals for SOX evidence?

Yes, GLPI's Assistance module is designed to create, follow and process tickets, problems and changes following ITIL practices, so it can hold the change request, the test reference and the approval trail in one place. The module also offers plannings, statistics and a Kanban view, which help show that changes moved through each stage. GLPI is licensed under GPL-3.0-or-later. Confirm in your own environment that the change workflow, required fields and approval steps are configured so that a ticket cannot close without test results and sign-off, and that the audit log and retention settings meet your records policy.

Is Zammad enough to track change requests from the business?

Zammad is a web-based helpdesk that brings requests from email, chat, telephone and social media into one ticket system, so it is well suited to capturing where a change request came from and who asked for it. It is licensed under AGPL-3.0-only. Many teams pair it with a change record system, because the request itself is only the start of the evidence. Confirm that requesters are identified reliably, that tickets link to the eventual deployment record, and that your change board or business owners approve in a traceable way before a change is scheduled.

How does GitLab protected branches help block untested code?

GitLab Community Edition (MIT licensed) supports protected branches, which let maintainers restrict which roles can push or merge to a branch. Setting push access to no one blocks direct pushes, and force pushes stay disabled unless explicitly allowed. Together these settings mean production-bound code can only enter through a merge request, which is where review and test results are recorded. Confirm in your environment that the protection is applied to the branches that feed production, that approval rules require reviewers other than the author, and that administrators cannot bypass the rules without a logged exception.

What does Semgrep Community Edition add to the change testing evidence?

Semgrep Community Edition (LGPL-2.1-only) scans code in languages including C/C++, C#, Go, Java, JavaScript, TypeScript, Python, Ruby, Rust, PHP, Kotlin, Swift and Terraform, using community or custom rules. It can run in CI/CD pipelines to scan repositories continuously, so each merge request can carry a scan result as part of its test record. This shows that automated checks ran before deployment, but it does not replace functional testing or user acceptance. Confirm which languages and rules cover your financial applications, whether scan results are retained with the change record, and how findings are triaged and approved.

Do these tools alone satisfy auditors testing change controls?

No single tool satisfies a SOX change control. Auditors look for a documented request, evidence of testing and user acceptance, and approval before the change reaches production, and they trace a sample of changes through that chain. The tools can hold each piece, but management must define the process, the required test evidence and who approves. Under PCAOB AS 2201, the evidence needed to show an automated control has not changed may depend on the strength of program change controls, so the chain has to be consistent. Confirm the process design with your auditor before relying on any tool output.

Who sets up these tools and who owns the evidence?

Management owns the controls and the evidence, including the approval decisions and the retention of records. An implementation partner can prepare and configure self-hosted open-source platforms inside your own infrastructure, set up workflows and document how they operate, under a written scope. Only an independent auditor issues conclusions on the controls. Confirm with your team which people will administer each tool, who can change the workflow settings, and how those administrative changes are themselves controlled and logged.

What should we check before relying on these tools for SOX evidence?

Start by confirming the licenses and editions against your own deployment, since the Community Editions and their terms should be verified for your use. Then check that each tool is configured to enforce the process rather than merely record it, that logs and records are retained for the period your policy and auditors require, and that access to the tools is itself restricted. Ask the auditor which sample populations and evidence formats they will request. Confirm the version and feature set in the vendor documentation for the exact release you deploy.

What does a change testing evidence setup cost to run?

The open-source licenses carry no license fee, but cost comes from people and infrastructure: configuring the workflows, hosting and patching the platforms, integrating them with the change process, and keeping evidence available for auditors. One-time work covers design and configuration, while recurring work covers administration, upgrades and periodic review of settings. Costs rise with the number of in-scope applications, the number of environments and the complexity of approvals. For a quote, ask for the scope of each tool, the integrations, the documentation deliverables and the support terms, since DeployOpen provides a quote based on a written scope rather than a published price.

Where to read the standards behind this control

The primary sources for change testing before production are the PCAOB filings that set out how external auditors test controls and assess IT risk, together with the SEC guidance management uses to evaluate its own controls. Start with the filing for *PCAOB Auditing Standard No. 5*, now AS 2201, which explains how auditors test whether automated controls can be relied on and why evidence that an automated control has not changed depends on the strength of program change controls. Read it alongside PCAOB risk assessment standards, including Auditing Standard No. 12 (now AS 2110), which covers the IT general controls an auditor must understand for automated controls and the IT risks that come from processing inaccurate data.

Management's own reference point is SEC Release 33-8810, the commission guidance on management's report on internal control over financial reporting. It explains that the IT general controls you evaluate are the ones needed for the proper and consistent operation of controls that address financial reporting risks, and it leaves the specific areas to your facts and circumstances. Read it with your own change population in mind: which applications, interfaces, databases and configuration tables feed financial reporting, and which test and sign-off records would show a reviewer that each change reached production only after the right people approved it.

Confirm two things before relying on any summary, including this one. First, check the current wording and status of each filing on the SEC and PCAOB websites, since AS 2201 and AS 2110 are the current designations of the earlier auditing standards. Second, ask your external auditor which version of the guidance and which testing approach it will apply to your change controls for the year under review. Your auditor's expectations for test scripts, user acceptance sign-off and retention of results are the detail that will decide whether your evidence holds up.

How DeployOpen prepares change testing evidence

DeployOpen plans, implements and documents the test and approval workflow inside your own infrastructure, so that changes to financially significant systems leave evidence an auditor can inspect. Your organization keeps ownership of its controls, and DeployOpen prepares the systems and records that show those controls operate.

How we scope

Engagements are fixed-scope, with the in-scope applications, environments and change types agreed in writing before work starts.
The written scope names which test environments, approval roles and test evidence types apply to financially significant changes.
We confirm with your team which change categories need full testing and which need a documented lighter path.

How we build

We configure the ticketing and repository workflow so each change links to a request, a test record and a named approver.
Protected branches and merge rules are set so that code cannot reach production without the required review step.
Test scripts, user acceptance sign-off templates and result retention are built to match the scope agreed with your team.

How we hand over

You receive documented procedures describing each step from change request through test sign-off and production release.
Sample evidence packs show how a single change traces from its ticket to test results, approval and deployment record.
Your staff are walked through the workflow so they can run it and answer an auditor's questions without outside help.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
We can review change samples periodically so gaps in test or approval records are found before the auditor's fieldwork.
Your independent auditor, not DeployOpen, decides whether the controls are effective and issues any report.