Why testing and go-live approval for new systems decides whether automated controls are trusted
When a financially significant system goes live or changes materially, the external auditor will ask one question early: how was it tested and who approved it for production? Under SOX Section 404, management must maintain effective internal control over financial reporting, and the program development area of IT general controls exists to show that new or changed systems were built, tested and released in a controlled way. The SEC's guidance names program development as one area management might consider, while noting that the relevant areas vary with each company's facts. For a new system, the practical requirement is evidence: a documented test plan, proof that the system's logic and interfaces produced correct results, user acceptance by the people who own the business process, and a recorded approval to move into production before any transaction is processed.
The risk is straightforward. A system that processes financial data inaccurately, released without proof of testing, can produce wrong balances that every downstream report inherits. The auditor's standards treat reliance on systems that process data inaccurately as an IT risk to internal control over financial reporting, so an untested configuration can undermine controls that look fine on paper. This area is hard for three reasons. Scope is often set late, so systems and interfaces that feed the ledger are discovered after testing has started. User acceptance evidence tends to be scattered across email threads, meeting notes and spreadsheets. And the test record must still be retrievable years later, when a control is tested again or an auditor asks how a baseline was established.
Start by confirming, with the project owner and your external auditor, which systems, interfaces and reports are in SOX scope before the test plan is written. Then require a single system of record for test cases, defects, sign-offs and the go-live approval, and check that each approval names the approver's role and is dated before the release. Ask whether the people approving user acceptance also have access to production, because that combination weakens the evidence. The test record is what allows the auditor to rely on an automated control in later years, so treat it as a permanent deliverable rather than a project artifact that gets archived in a shared drive.
Which new systems and changes fall inside SOX go-live testing
Scope for go-live testing starts with which new systems, interfaces and changes touch financial reporting risks. The decisions below determine how many systems need testing, who signs off, and how much evidence the auditor will expect before a new automated control is baselined.
Financially significant applications and modules
Start with the systems that originate, process or summarize transactions feeding the financial statements, such as general ledger, subledgers, consolidation and reporting tools. A new module that posts journal entries or calculates reserves is in scope even if the vendor sells it as a minor add-on. Confirm the list against the financial statement risk assessment, not against the project plan, because project plans often omit reporting tools and spreadsheets that feed them.
Only the ITGCs needed for other controls
SEC guidance in Release 33-8810 says management evaluates only the IT general controls necessary for the proper and consistent operation of controls that address financial reporting risks. Go-live testing for a system that only improves operational efficiency can be narrowed accordingly. Document the reasoning in writing, because the auditor will ask why a system was excluded.
Interfaces and data feeds
An interface that moves balances, invoices or payments into a financial system can introduce completeness and accuracy errors even when both endpoints are in scope. Test each inbound and outbound feed for transmission, mapping and error handling, and include scheduled file transfers and middleware. Auditors evaluate IT risks such as reliance on systems that process data inaccurately, so an unmonitored feed is a scoping gap.
Configuration changes and major upgrades
A major version upgrade or a change to posting rules, approval limits, tax tables or account determination can alter an automated control without touching custom code. Treat these as in scope when they change how transactions are recorded or approved. Ask the project team to list every configuration object that drives a financial calculation, and compare that list with the controls already tested in the prior year.
Finance process owners, IT and the project team
Finance process owners define what the system must get right and who approves transactions, so they should confirm test scripts and acceptance criteria. IT owns the environments, access provisioning and promotion path, and the project team runs build and test activity. Assign one accountable owner for go-live approval, and record each team's sign-off so the auditor can trace who decided the system was ready.
Third-party-hosted and service provider systems
A SaaS or outsourced system does not remove testing responsibility, because management still needs evidence that the system was tested and approved before use. Confirm whether the provider's implementation testing, change records and release notes can be obtained, and whether the provider's report covers the period of implementation. Where the provider cannot supply evidence, plan internal testing of the configured functionality that affects financial reporting.
How go-live evidence sets the baseline for automated controls
An auditor does not retest a new automated control in every year of the audit. The go-live testing record establishes a baseline for that control, and later years can rely on that baseline only while the surrounding IT general controls remain effective. Under PCAOB AS 2201, reliance depends on three things holding at the same time: general controls over program changes, access and computer operations are effective, and the control itself has not changed. If the change ticket, approval and access records for the system are weak, the pre-production test result loses most of its value for the next audit, and the auditor must test the control again instead of relying on the baseline.
For that reason, the go-live file should be built for future reliance, not only for the approval meeting. Keep the test scripts, the exact configuration or program version tested, the test data and expected results, the defect log with resolutions, and the signed approval to move to production, all tied to one identifier for the control. Confirm with your auditor which version of the control description they will use as the baseline reference, and confirm how your team will show that the production configuration matches the tested configuration. A later change to a validation rule, approval limit or calculation, even one made as a routine configuration update, is a change to the control that must go through the change process again.
The baseline also has a limited life. AS 2201 says the baseline should be reestablished after a period that depends on circumstances, including the strength of the IT control environment, so a stable system with clean change and access records may be relied on for longer than one with recent findings. AS 2110 adds that reliance on systems or programs that process data inaccurately is an IT risk to internal control over financial reporting, so the auditor will look at whether the system's outputs were validated after go-live. Ask your auditor early how they plan to set the re-baselining interval for each new control and what evidence will prompt them to test it sooner.
How to build a test and approval cycle before go-live
This sequence turns requirements into evidence that a new financially significant system works as intended, that the people who own the results accepted it, and that the approved version is the one that reaches production. Each step produces a named artifact that an auditor can trace from control objective to go-live.
Define requirements and control objectives
The finance process owner, the system owner and IT agree on what the system must do for financial reporting, including calculations, approvals, interfaces and reports that feed the financial statements. The team records these as a requirements document with a control objective for each item, and it flags which automated controls the business expects to rely on. The step is done when the business owner signs the requirements and every financially relevant requirement maps to at least one planned test. This document also tells the auditor later which controls need a baseline.
Write test scripts for calculations and interfaces
Testers, with business analysts, write scripts that cover financial calculations, rounding, cutoffs, approval thresholds and every interface that carries financial data in or out of the system. Each script states its inputs, expected results, the data set used and who will execute it. The test plan records scope, environments, entry and exit criteria, and the tool used to track results. The step is complete when the plan is reviewed by someone outside the project team and the scripts are stored under version control so later changes are visible.
Run system and integration testing
The test team executes the scripts in a controlled test environment that resembles production in configuration, although not necessarily in volume. They confirm that interfaces transmit complete and accurate records, that error handling rejects bad data, and that calculated results match the expected values. Each execution is logged with the tester, date, environment, build identifier and outcome. The step closes with a test execution report that shows pass, fail and blocked counts against the plan, so reviewers can see what was tested and what was not.
Run user acceptance testing with business sign-off
Business owners, not the project team, execute acceptance scenarios that reflect how their processes will run after go-live, such as month-end close, reconciliations and exception handling. They compare outputs with source records and confirm that the system supports their approval workflow. Each owner signs a UAT acceptance form that names the scenarios covered and any accepted known issues. The step is done when every owner who depends on the system has signed, and the form is retained as evidence of who accepted the results and on what basis.
Record, triage and resolve defects
Every defect found during testing goes into a defect log with a description, severity, the requirement or control it affects, an owner and a status. Severity decisions that touch financial accuracy are reviewed by the finance owner, not closed by the developer alone. Fixes are retested, and the retest result is attached to the original defect. The step is complete when no open defect affects a financially significant requirement, or each remaining item has a documented workaround approved by the business owner. The log is one of the first items an auditor requests.
Freeze the release and obtain formal approval
The team locks the code, configuration and data migration scripts that will go to production, and records their versions and checksums or commit identifiers. A go-live approval form then lists the release identifier, the test results, open defects with accepted risks, the rollback plan and the approvers, who typically include the system owner, finance and IT. The release may not move forward until these approvals are recorded. The frozen release becomes the reference point for any later comparison of what changed.
Deploy and record access and change details
The deployment follows the approved change record and runs only the frozen release. The change record captures who performed each action, the timing, any emergency changes and the verification performed after cutover, such as confirming that the production configuration matches the approved release. Production access used for the deployment is granted through a documented request and removed afterward. The step closes with a post-implementation check that confirms the system is live as approved, and the change and access records are stored with the approval form so the evidence chain stays complete.
How an assessor tests testing and go-live approval
This table lists the steps an external auditor typically takes to test pre-implementation testing and go-live approval, the evidence each step requests, and the findings that most often come up. Read each row as a question the auditor will ask and the documents that answer it. The main takeaway is that approvals must be dated before deployment and signed by people with authority, because a release can only be relied on if the approved version is the one running in production.
| Test approach | Evidence requested | Common findings |
|---|---|---|
| Walkthrough of the go-live process from change request to production deployment | Written go-live procedure, a sample change request traced end to end, and the names of people who perform each step | Process is undocumented, or the steps performed differ from the written procedure |
| Inspection of the test plan and test scripts for the new system and its interfaces | Approved test plan, scope statement, test scripts covering financial calculations and key reports, and interface test cases | Test plan does not cover key financial logic or interfaces that feed the general ledger |
| Sampling of test cases and defect records | Test execution results with tester name and date, defect log showing severity, fix and retest | Critical defects closed without retest, or open defects accepted without a documented business decision |
| Inspection of user acceptance testing sign-off | Signed UAT approval listing the version tested, the approver's name and role, and the approval date | UAT signed by people without authority over the process, or signed before testing finished |
| Inspection of go-live approval | Approval record dated before the deployment, showing who approved production release and on what basis | Approval dated after deployment, or approval that does not name the version released |
| Checking production access at deployment | List of accounts with deployment rights, approval for each, and log of who deployed and when | Developers or vendor staff deployed to production without an approved access grant |
| Comparing the approved release to what runs in production | Release package hash or version identifier, and a production configuration or code comparison against the approved build | Production differs from the tested build, which breaks reliance on prior testing |
| Testing interfaces and data feeds into the new system | Interface test results, reconciliation of records passed between systems, and sign-off on interface behavior | Interfaces to the general ledger or subledgers were not tested before go-live |
Evidence that passes a go-live test and how to keep it current
An auditor baselines a new automated control only when the test record, the approval and the deployment trail agree with each other. The cards below cover the artifacts that satisfy that chain and the open-source tools that can keep it current between audits.
Test plans and executed scripts
A test plan should state the requirement each test covers, the data used, the expected result and the tester. Executed scripts should record the actual result, the date, the tester and the reviewer, with failures linked to defect records. Auditors look for scripts that were run against the release candidate that was later deployed, not an earlier build. Confirm that test data reflects the financial logic being tested, including edge cases such as rounding, currency and period-end cutoffs.
User acceptance sign-offs
UAT sign-off shows that the business owners of the financial process, not only the project team, accepted the system's behavior. Each sign-off should name the approver, identify the version tested, reference the test cases accepted and carry a date earlier than the go-live date. Confirm that approvers have business authority over the process and that sign-offs cannot be given by the same person who built or configured the change.
Defect logs with resolution records
A defect log lists each issue found during testing, its severity, its owner and the fix or accepted risk with the approver's name. Auditors sample defects to confirm that open items at go-live were assessed and accepted by an appropriate person. Ticketing tools such as GLPI or Zammad can hold these records, but the link between each defect, its fix and the release must be traceable, not only stored.
Protected branches for release traceability
GitLab Community Edition provides protected branches that let maintainers restrict which roles can push or merge to a branch, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. These settings help show that production code only changed through reviewed merges, so each release can be traced to an approved change. Confirm with your edition's documentation which protection options are included, because the Community Edition license is MIT.
Continuous code scanning records
Semgrep can run in CI/CD pipelines to scan repositories continuously across languages including Java, Python, JavaScript, Go and Terraform. Each pipeline run produces a record of which rules ran, what was flagged and what was blocked or accepted. Those records support the claim that changes were checked before deployment. Semgrep Community Edition is licensed under LGPL-2.1-only, and readers should confirm which rules, reporting and enforcement features apply to their chosen edition.
ITIL change records in GLPI
GLPI's Assistance module lets users create, follow and process tickets, problems and changes following ITIL practices, with plannings, statistics and a Kanban view. For go-live, a change record should link the test evidence, the UAT sign-off and the approval dated before deployment, and it should capture the actual deployment time. GLPI is licensed under GPL-3.0-or-later. Confirm that its change workflow includes the approval step and retention settings your auditors expect.
Defect and request intake with Zammad
Zammad is a web-based helpdesk that gathers email, chat, telephone and social media messages into one ticket system. It suits defect and request intake during testing, especially when business users report issues outside the project team's channels. Keeping intake in one queue means every reported defect has an owner and a timestamp. Zammad is licensed under AGPL-3.0-only, which carries source-availability obligations for modified network services, so confirm this with counsel before deployment.
Keeping evidence current between audits
Auditors may need to see that a baselined control is still valid, so evidence should be collected as work happens rather than rebuilt before an audit. Set a schedule to review access to the repositories, confirm protected branch settings, retain pipeline and ticket records under a defined retention period and re-test controls when code or configuration changes. Confirm with your auditor how long the baseline holds and which triggers require reestablishing it.
What testing and go-live approval costs to meet
This table breaks down the cost components of pre-implementation testing and go-live approval, showing who is paid, whether each cost is one-time or recurring, what drives it up, and how to contain it. Use it to build a written scope and to compare quotes line by line. No fee or duration is stated because none was supplied, so the figures come from your own scope and vendor quotes.
| Cost component | One-time or recurring | What drives it up | How to keep it down |
|---|---|---|---|
| Test tooling and licenses | Recurring license or subscription, plus one-time setup | Number of named users, environments and test management seats; commercial test suites with per-user fees | Use self-hosted open-source test tracking and ticketing such as GLPI, but budget for hosting, configuration and upkeep |
| Engineering and QA time for test design | One-time per release, with recurring rework | Number of interfaces, number of modules in scope and how often requirements change | Write test cases once against documented requirements and reuse them for each release |
| Engineering and QA time for test execution | Recurring for each release and each emergency change | Number of releases per year and how much testing is manual | Automate regression tests where practical and record results in the ticket or change record |
| Business owner time for UAT | Recurring for each release, and one-time for initial acceptance | Number of business units, number of process owners and number of sign-offs required | Define acceptance criteria up front and limit UAT to the scenarios that affect financial reporting |
| Go-live approval workflow | Recurring for each change | Number of approvers, number of approval gates and manual evidence collection | Use a ticketing workflow with defined approvers and attach test results to the approval record |
| Interface and data testing | One-time per interface, with recurring regression runs | Number of interfaces, volume of records and frequency of upstream changes | Maintain a single interface inventory and rerun reconciliation checks for each change that touches data flows |
| Evidence upkeep | Recurring, through the life of the system | Number of systems, retention periods and inconsistent storage of test artifacts | Store approvals, test scripts and results in one controlled repository with consistent naming |
| External testing or review | Usually one-time per implementation, plus periodic review | Scope of independent review, depth of security testing and number of findings to retest | Confirm the reviewer's scope in writing before work starts and avoid open-ended engagements |
| Auditor sampling and walkthroughs | Recurring each audit cycle | Number of new automated controls to baseline, number of changes sampled and any deficiencies found | Give the auditor complete, organized evidence for each sampled change so that sampling does not expand |
Who owns go-live testing, who can help, and where the auditor stops
Your organization owns the control. Management decides whether a system is ready to enter production, records who approved that decision, and keeps the records that prove it. Those responsibilities cannot be handed to a vendor or consultant, because the approval is what the auditor tests. Your team defines test scope, accepts the results, and signs off the business outcome for each financially significant process.
- Approval decisions: Named business owners and IT owners approve go-live based on documented test results, open defect status and rollback criteria.
- Test strategy and scope: Management decides which functions, interfaces and reports are in scope, based on the financial reporting risks each one affects.
- User acceptance: Business users execute or review acceptance testing and confirm that the outputs match approved requirements.
- Record retention: Requirements, test cases, defect logs, approvals and migration sign-offs are kept in a system that stays available for the audit period.
- Segregation of duties: The people who build a change should not be the only people who approve its move to production.
Before relying on any partner's work, confirm in writing which approvals and records remain under your control and who can produce them on request.
An implementation partner can prepare the technical environment that makes testing and evidence collection repeatable. Typical work includes building non-production environments, writing test scripts, configuring pipeline checks, and setting up the ticketing and repository controls that capture evidence automatically. The partner prepares these artifacts for management to review and approve. It does not make the go-live decision or substitute its own sign-off for the business owner's.
- Test environments: Partners can stand up isolated test and staging environments that mirror production configuration closely enough for meaningful results.
- Test scripts and data: Partners can draft scripts for regression, interface and reconciliation tests, which management then reviews and approves.
- Pipeline and repository checks: Partners can configure protected branches, required reviews and automated scans so that promotion steps leave a traceable record.
- Evidence collection: Partners can set up ticket workflows and exports that link requirements, tests, defects and approvals.
- Usually outsourced versus kept in-house: Tooling, scripts and environment builds are often outsourced. Scope decisions, acceptance and approvals usually stay with management.
Ask any partner to describe in writing which artifacts it will produce, who approves each one, and where the evidence will be stored after handover.
The external auditor tests whether management's go-live controls operate effectively. Under PCAOB AS 2201, the auditor evaluates the design of controls and tests operating effectiveness by inspecting selected samples of evidence. The auditor also uses this evidence to decide whether a new automated control can be baselined and relied on in later years. The auditor does not design the controls, prepare the test scripts, or perform the approvals on management's behalf, because doing so would compromise independence.
- Design evaluation: The auditor reviews whether the documented approval and testing process would reasonably catch defects before go-live.
- Sample testing: The auditor selects changes or releases and inspects the requirements, test results, approvals and migration sign-offs for each.
- Baseline decisions: The auditor checks whether general controls over program changes, access and computer operations were effective, and whether the automated control has changed, before relying on a baseline.
- Independence limits: Auditors may explain expectations and point out gaps, but they should not write your test cases or approve your releases.
- Evidence requests: Auditors request evidence from the records management keeps, so those records must be complete and retrievable.
Confirm early with your auditor which samples and evidence formats it expects, so that the testing you design can be inspected without rework.
Where go-live approvals usually fail the audit
Auditors test new systems by asking whether the approval, testing and access evidence existed before the system went live and whether it can be retrieved later. The gaps below cluster around timing, scope and storage, and each one has a closing action that can be checked before the next release.
Approval recorded after deployment
A go-live sign-off dated after the release date tells the auditor that production came first and approval followed. Auditors compare the approval timestamp with the deployment record. Close the gap by making the signed approval a gate in the change workflow, so the ticket cannot move to deployed until the approver has recorded a decision. Check that the approval date and the deployment log agree for every release in the period.
UAT without documented scope
User acceptance testing that has no written test scope, test cases or defined pass criteria gives the auditor nothing to test against. Reviewers ask who chose the scenarios and whether financially significant paths were covered. Close the gap by approving a test plan before testing starts, listing the business processes and reports in scope, and recording the pass or fail result for each case with the tester's name.
Interfaces and conversions untested
New systems often pass their own tests but fail when data arrives from upstream feeds or when migrated balances do not reconcile. An untested interface can silently drop or duplicate transactions. Close the gap by including every interface and conversion load in the test plan, with record counts and control totals reconciled between source and target and the reconciliation signed before cutover.
Production access not restricted at release
Developers who keep production rights after go-live can change the system outside the approved process, which weakens every control tested before release. Auditors look for the access list on the day of cutover. Close the gap by removing deployment and administrator rights from the build team once the release is complete, and by documenting the emergency access process with its own approval and review.
Evidence kept in personal folders
Test results, screenshots and approval emails stored in personal drives or inboxes disappear when staff leave and cannot be shown to the auditor on request. Close the gap by storing the test plan, results, approvals and deployment records in one controlled repository with restricted write access and a defined retention period that covers the audit period.
No baseline reassessment after changes
An automated control tested once at go-live is not automatically reliable in later years. Auditors may rely on a baseline only while the control has not changed and related general controls work, and the baseline must be reestablished after a period that depends on the IT control environment. Close the gap by logging every later change to the control's logic, tagging it in the change record, and scheduling a retest when the change is made.
Questions buyers ask about go-live testing evidence and outside help
How much effort does go-live testing add to a system project?
The effort depends on how many financially significant processes, interfaces and reports the new system touches, and on how many test cycles the team needs before sign-off. Testing usually runs alongside configuration and data conversion, so the extra work is mostly the time to write test scripts, run them, log defects, retest fixes and keep the results in a form an auditor can read. No duration or cost figure is supplied for this work, so ask your project team or a prospective partner to size it from your own scope list, interface count and number of key reports before you approve a budget.
How long does preparation for go-live testing take?
It depends on the scope of the system and the project plan, and no standard duration applies. Preparation covers defining test scenarios tied to key controls, building test data, confirming environments and agreeing acceptance criteria before any testing starts. A narrow change to one module will need far less preparation than a new ERP with several interfaces. Ask for a written schedule that shows each preparation step, the owner of each step and the dependency on the data conversion workstream.
What does go-live testing need from our own staff?
It needs three things from your company: business owners who can write and sign off user acceptance tests for the processes they run, IT staff who can provision and control the test and production environments, and one named approver with the authority to accept the risk of moving to production. Without those roles filled, testing drifts and the sign-off has no weight. Confirm who holds each role before the project starts, because auditors will ask who approved the change and whether that person had the authority to do so.
Can our internal team run go-live testing without outside help?
Yes, many companies run this work in-house, and the control does not require an outside party. The questions to answer honestly are whether your team has done a comparable go-live before, whether it can keep test evidence separate from the people who built the system, and whether it has capacity during the cutover window. Teams that lack recent SOX experience often struggle most with evidence quality, such as showing who tested what, when, against which version and with what result.
What can an implementation partner take off our team?
A fixed-scope implementation partner such as DeployOpen can plan the test approach, set up and harden the environments, script and run technical and integration tests, document configuration and keep the evidence organized for review. The partner prepares systems and evidence. It does not own your controls, decide whether the system is ready for your business, or issue any audit report. Your company keeps accountability for approving go-live. Agree the split of tasks in writing, including who maintains the test evidence after handover.
What will the external auditor do with our go-live evidence, and what won't they do?
The external auditor will read your go-live evidence to understand the new automated controls, decide whether the testing and approval support a baseline, and check whether general controls over program changes, access and computer operations stay effective afterward. Under PCAOB AS 2201, a baseline of an automated control can only be relied on in later years while those general controls remain effective and the control has not changed. The auditor will not design your testing, run your user acceptance tests or approve your go-live, because that work belongs to management.
How do we get a written quote for go-live testing support?
Start with a written scope that lists the systems, interfaces, key reports, environments, test cycles and deliverables you need, along with the target go-live window and who on your side owns each area. Ask the provider to state its assumptions, the roles it expects from your staff, what is included in the fixed price and what would trigger a change order. DeployOpen does not publish a price list, and a quote follows from the agreed written scope. Ask any provider to separate one-time project work from any recurring support or retesting after go-live.
How DeployOpen prepares go-live testing and approval evidence
DeployOpen prepares the systems, test records and approval workflow that show a new financially significant system was tested and formally approved before it reached production. The organization keeps ownership of its controls, and an independent auditor issues any report on them.
How we scope
- Agree the written scope for each new system, interface and release before work starts, including which financial reports depend on it.
- Define which test types, user acceptance groups and approval roles are in scope for testing and go-live approval.
- Confirm with the client which environments, ticketing records and repositories will hold the evidence auditors will request.
How we build
- Configure a ticketing workflow that records requests, test plans, test results, defects and go-live approvals in one traceable chain.
- Set up protected branches and separate test and production environments so that changes cannot move to production without recorded sign-off.
- Document test scripts, expected results and retest steps so reviewers can compare actual outcomes against approved expectations.
How we hand over
- Deliver a go-live evidence pack that maps each test and approval record to the system and control it supports.
- Provide written procedures that explain who approves testing, who approves go-live and how exceptions are logged and escalated.
- Walk the client's control owners and internal audit through the evidence so they can answer auditor questions without DeployOpen present.
How we support
- Offer ongoing support and upgrade testing as a retainer, so later releases follow the same approval path.
- Review evidence completeness before each interim or year-end test window, based on the agreed scope.
- Confirm with your external auditor which records they expect for baselining automated controls, since their requirements vary by company.
