SOX ITGC testing in later years: reduced testing rules

How does SOX ITGC testing change in later years?

A second-year audit often starts with a budget question: can the ITGC testing shrink because the controls worked last year? It can, but only where prior results and unchanged controls support a lower risk assessment. The external auditor makes that call, not the company. Under PCAOB AS 2201 (paragraphs 57 to 59), the auditor may use knowledge from prior years, including earlier results and any changes to the control or process, to assess risk as lower and reduce testing. Management should expect that request to be tested against its own change history before it is accepted.

The organization still owns its controls and the evidence behind them. An implementation partner such as DeployOpen can prepare and organize that evidence, for example by assembling the change tickets, access review records and job logs that show whether a control changed and whether its related general controls kept working. Only the independent auditor issues the attestation. Ask your team to confirm, with the auditor early in the year, which prior-year results and which change records will be accepted, and to confirm how the auditor will report them in the work plan.

Reduced testing also has limits. AS 2201 (paragraph B29) allows reliance on a baseline of an unchanged automated control in later years only if the general controls over program changes, access and computer operations are effective and continue to be tested. AS 2201 (paragraph 61) also requires the auditor to vary the nature, timing and extent of control testing from year to year, so a shrinking plan still changes shape. AS 2201 (paragraph B33) says the baseline should be reestablished after a period that depends on circumstances, including the IT control environment. Plan for a new baseline after a significant system change, a failed control or a staffing change in the control owner role, and confirm the reestablishment period with your auditor rather than assuming it.

Which later-year testing approach fits a control

An automated control that has not changed since it was last tested can, in some cases, be tested by establishing a baseline and confirming that the baseline still holds. Paragraph B29 of AS 2201 allows reliance on that baseline in later years only when general controls over program changes, access and computer operations are effective and continue to be tested. The reduction depends on the general controls, not on the automated control alone.

What may be reduced: Repeated testing of the automated logic, provided the baseline evidence from the prior year still describes the configuration in use.
What must still be tested: Program change controls, access controls and computer operations, each tested again every year.
Evidence that supports it: Prior-year baseline results, change tickets showing no modification to the logic or configuration, and current-year proof that the relevant general controls operated.
Baseline reestablishment: Paragraph B33 says the baseline should be reestablished after a period that depends on circumstances, including the IT control environment, so confirm the interval with the auditor.
Hidden changes: Vendor patches, parameter tables and database changes can alter behavior without a visible code change, so check them against the change log.

Confirm with the auditor in writing which general controls they regard as effective before planning any reduction.

When does an automated control need a new baseline?

An automated control keeps its baseline only while the logic behind it stays the same. PCAOB AS 2201 (paragraph B33) says the baseline should be reestablished after a period of time that depends on circumstances, and it names the IT control environment as one of them. The standard sets no fixed interval, so the team has to decide when a baseline has aged out and document why. Treat the baseline as valid only for as long as the evidence still shows the control is the same control that was tested.

Several events should prompt a review of the baseline before the next reliance decision. Major system upgrades, patches that touch the calculation or report logic, and configuration changes to tolerances, thresholds, approval routing or interfaces all change what the baseline proves. Weak results from the program change controls, access findings on the production application or its database, and problems in computer operations such as failed batch jobs also weaken the basis for reliance, because the baseline depends on those general controls operating effectively. A new environment, such as a migration to a different hosting model or a new instance of the application, usually starts a new baseline outright.

Confirm the expected reestablishment interval with the external auditor before the fiscal year begins, not at year end. Ask which triggers the auditor treats as automatic, whether a patch that changes no financial logic needs a fresh baseline, and what evidence it expects to see. Record the decision in the testing file: the triggers reviewed, the change history checked, the conclusion reached and the date the next baseline is due. A documented, reasoned interval is easier to defend in an inspection than a baseline that simply carried forward.

What makes later-year testing lighter or heavier

Auditors can reduce ITGC testing in later years only when they can rely on what they learned before. The factors below decide whether that reliance holds, and each one points to specific evidence the auditor will ask for.

Quality of prior-year results

Clean prior-year testing with no ITGC deficiencies is the starting point for lower assessed risk. If the prior year found exceptions, the auditor starts with a wider sample and may not carry results forward at all. Check whether last year's deficiencies were fully remediated and whether the fix was tested, not just reported. Auditors will ask for the prior-year workpapers, the deficiency log and the remediation evidence that closed each item.

Volume of changes in the period

The more changes a financially significant system receives, the more chances there are for an unauthorized or untested change to reach production. A stable system with few releases supports reduced testing, while frequent patches, configuration updates or emergency fixes call for broader sampling. Pull a full change population report early so you can show the count and that it is complete. Auditors will ask for that population and will test whether it matches the change tickets they select from.

Strength of change and access controls

Reliance on an unchanged automated control in later years depends on general controls over program changes, access and computer operations being effective and continuing to be tested. If a control over who can move code into production or who holds administrative rights has weakened, the baseline of the automated control cannot be trusted. Review privileged access lists, segregation between developers and deployers, and emergency access logs before the year begins. Auditors will ask for quarterly access reviews, approval records and privileged activity logs.

Number of locations or business units

Testing has to vary by location or business unit from year to year, so a company with many entities or instances has more to plan for each cycle. Every additional instance of a financial application adds a population to test, and each may have its own change and access processes. Keep a current list of in-scope locations, the systems each one uses and who owns each. Auditors will ask for that inventory and evidence that the locations selected for testing rotate and are covered over time.

Use of third-party and cloud providers

When a SaaS provider or managed host runs a financial system, the company still owns the ITGCs that its own users and administrators perform, and it must obtain evidence about what the provider controls. A change in provider, a new service organization report or a shift in responsibilities can alter the baseline. Confirm which controls the provider covers in its report, map the gaps to your own controls and track any exceptions or complementary user entity controls. Auditors will ask for current provider reports, the bridge letters that cover the gap in their period and evidence of your own review.

Quality of change records

Reduced testing depends on being able to show, for each change, who requested it, who approved it, what testing was done and when it moved to production. Incomplete tickets, approvals given after deployment or changes made outside the tracking tool make the population unreliable and push the auditor toward heavier testing. Reconcile the change tracking system to deployment logs at least periodically to confirm every production change is recorded. Auditors will ask for the complete ticket with approval timestamps and test evidence, plus the reconciliation itself.

How the year-two cycle runs from planning to the auditor's conclusion

The year-two cycle turns last year's test results and change history into a documented decision about how much testing each automated control still needs, then produces evidence the external auditor can use in its own risk assessment. Each step ends with a named output that feeds the next.

Review prior-year deficiencies and remediation
Management starts by pulling last year's ITGC results: every deficiency, its root cause, whether it was remediated, and whether remediation was tested before year end. The control owner for each area confirms the facts, and the SOX lead signs off on the list. The output is a prior-year findings register that shows which controls failed, which were fixed, and which remain open. Any control with an unresolved or unverified deficiency is excluded from reduced testing until the gap is closed and retested.
Pull change history for automated controls
For each in-scope automated control and the program change, access and computer operations controls that support it, the team extracts change records from the ticketing system, source control and privileged access logs for the period since the last baseline. Each change is tagged by system, nature and approval status. The output is a change inventory per automated control. An empty or incomplete change history is itself a finding to resolve before the team relies on any baseline.
Assess whether reliance is still supportable
The team compares the change inventory against the baseline and decides, control by control, whether the automated logic is unchanged and whether the supporting general controls were effective and continue to be tested. It also checks whether the baseline is too old under its own IT control environment. The output is a reliance memo that records each control as relied upon, retested or rebaselined, with the reasons. Controls with unauthorized changes or weak general controls move back to full testing.
Set the varied test plan for the year
Using the reliance memo, the team designs the year's test plan. It changes the sample items, timing of testing, the mix of locations or business units, and the testers where these variations are practical, so the plan is not identical to last year's. The plan states the objective, population, sample approach and evidence required for each control. The output is an approved test plan that the control owners and the auditor can review before fieldwork begins.
Perform testing and document results
Testers execute the plan, obtaining evidence directly from systems or reports and recording what was inspected, reperformed or observed. Exceptions are logged immediately with the population and sample they came from, and any exception is assessed for its effect on the controls that depend on it. The output is a set of workpapers that another tester could reperform, linked to the plan and the evidence files. Testing is complete when every planned procedure has a conclusion and every exception has an assessment.
Conclude and hand results to the auditor
Management reaches a conclusion on each control's design and operating effectiveness, updates the reliance memo and documents any deficiencies with their severity assessment. The package goes to the external auditor, which uses it in its own risk assessment under its standards, and it decides how much of the work it can rely on. The output is a delivered results package with a log of questions and responses. The auditor's conclusion, not management's, determines the final testing it performs.

What to have ready before the auditor relies on prior work

Reduced testing in later years depends on the auditor being able to rely on what was tested before. Each record below either proves the prior conclusion still applies or shows that something changed, so check each one for completeness before fieldwork starts. Management should confirm these records with its own reviewers, since the auditor will test whatever management presents.

Current control inventory

Keep a dated list of every automated control, configuration setting, report and interface in SOX ITGC scope, with its owner and the system version it runs on. The auditor compares this list against last year's to decide whether a baseline still describes the control. Check that every item from the prior-year walkthroughs appears, that no new interface or report has been left out, and that version numbers match what is in production.

Complete change tickets

Each change to a financially significant application or configuration needs a ticket that shows the request, approval, testing and production release. Reuse depends on this record, because a baseline is only valid if changes were controlled. Pull the full population of changes for the period and confirm that the count matches the change log from the platform, that approvals came before deployment, and that emergency changes have after-the-fact review.

Access review records

Periodic access reviews show that users and privileged accounts were confirmed as still needed. Keep the review sign-offs, the population reviewed and the list of removals with their dates. Before the auditor asks, compare the review population to a current user extract to confirm no accounts were missed, and check that terminated and transferred staff were removed on time.

Job monitoring and backup logs

Scheduled jobs, batch processing and backups are the computer operations evidence that the system kept running completely and accurately. Keep the job logs, failure alerts and restore test results for the full period. Confirm that the logs cover every day or cycle in the period without gaps, that failures were investigated and resolved, and that restore tests were performed on the schedule the team documented.

Dated prior-year conclusions

Record what was tested, what was concluded, which deficiencies were found and how each was remediated, with dates and the names of those who reviewed the work. This record tells the auditor exactly where the prior baseline stands and whether any control has already failed. Confirm that each prior-year conclusion links to the underlying evidence, that open deficiencies are noted, and that any change to a control since the prior year is flagged for re-testing.

Questions teams ask about reduced SOX ITGC testing

Can we skip testing an unchanged automated control entirely in later years?

Not on the strength of management's say-so alone. The auditor may use knowledge from prior years, including earlier results and any changes to the control, to assess risk as lower and reduce testing. For an unchanged automated control, the auditor may rely on a baseline established earlier only if the general controls over program changes, access and computer operations are effective and continue to be tested. Those general controls are the foundation, so they stay in the annual testing cycle. The baseline also has an expiry: it must be reestablished after a period that depends on circumstances, including the strength of the IT control environment. Ask your auditor in writing how they plan to treat each automated control before you assume any reduction.

Does rotation mean testing a different sample each year?

Rotation means varying the nature, timing and extent of testing from year to year so the auditor's procedures are not predictable. It does not mean skipping a control because it was tested last year. In practice, the auditor might change the procedures used, the period covered, or the population or locations selected, while still covering the controls that need annual evidence. The same principle applies across locations and business units, where the auditor varies coverage from year to year. For management, the practical point is that evidence should be easy to produce for different samples and periods, so the control owner is not rebuilding the evidence trail each time.

Who decides how much SOX ITGC testing can be reduced?

The external auditor decides the extent of its own testing, and management decides the extent of its own assessment under Section 404(a). Neither side can hand that decision to a consultant or a vendor. Management sets its approach based on its risk assessment, prior results and changes in the environment, and the auditor evaluates whether that approach supports its opinion. A reduction in one party's work does not automatically reduce the other's. Management should agree the planned approach with the auditor early in the year, document the reasoning, and keep the change history that supports any lower-risk conclusion.

Does a deficiency end our ability to rely on prior results?

Usually it changes the picture significantly. Prior results and an unchanged baseline support lower risk only when the relevant general controls keep working. A deficiency in program change management or access, for example, undermines reliance on the automated controls that depend on them, and the auditor may need to retest from a fresh baseline or test more extensively. The effect depends on the severity of the deficiency, whether a compensating control exists, and whether it was remediated before the assessment date. Treat any deficiency as a reason to reexamine reliance, and document the impact on dependent controls.

Can our internal team handle reduced testing without outside help?

Often yes, provided the team can show it is competent and independent of the controls it evaluates. Management must maintain its own evidence, perform or monitor the testing, and keep the documentation that lets the auditor reperform or assess the work. The main questions are whether the team understands the systems and the change history well enough to judge risk, and whether the people testing are separate from the people operating the controls. Smaller teams often find that the hardest part is maintaining a clean record of changes and reviews year after year, not running the tests themselves. Confirm the approach with your auditor before the year begins.

What does an implementation partner change in later-year testing?

An implementation partner can prepare systems and evidence so that the controls produce consistent records year after year. That work may include configuring change approval workflows, access review reports, job monitoring and log retention in your own environment, plus documenting how each control operates and how its evidence is matched to risk. A partner does not decide how much testing the auditor performs, does not issue the Section 404 conclusion, and does not replace management's ownership of its controls. Ask any partner to state in the written scope which evidence they will prepare, who will review it, and how the work will be handed over to your internal team.

When do we need a new baseline for an automated control?

You need a new baseline when the control or the environment around it has changed in a way that could affect how it works, and when the period since the last baseline is too long given your IT control environment. PCAOB guidance does not set a fixed number of years, so the right interval depends on your circumstances. Common triggers include a system upgrade, a configuration change to the control logic, a change in the people or tools that operate it, or a deficiency in a general control it depends on. Keep a dated change log for each automated control so you can show the auditor when a baseline was last established and what has changed since.

Common reasons reduced testing fails at audit

Reduced testing in later years depends on a defensible baseline, a complete change history and a documented rotation plan. The cards below cover the failure points auditors most often find when a team relies on prior-year work to test less.

Relying on a baseline with gaps

A baseline of an unchanged automated control can only be carried forward if the general controls over program changes, access and computer operations were effective and were tested in the same year. If the prior year showed a deficiency in any of those areas, the baseline is weakened and the auditor cannot simply reuse it. Before reducing testing, confirm that each relevant general control had no unremediated exceptions and that it was tested in the current year.

Undocumented changes breaking the baseline

A baseline assumes the automated logic has not changed since it was last tested. Emergency fixes, vendor patches, configuration edits and direct database changes that bypass the change process can alter that logic without leaving a record the auditor can match. Reconcile the change management log, ticketing records and deployment history against the control's baseline before each year's testing decision, and treat any unexplained difference as a reason to retest.

Rotating locations without a plan

Varying testing across locations or business units from year to year is expected, but the rotation has to be planned and recorded. A rotation that skips a location with recent system changes, a new acquisition or a staffing gap leaves the risk untested. Write down the rotation criteria, the reason each location was selected or deferred, and how risk ratings for the skipped locations were reviewed.

Treating a patched system as unchanged

A security patch, version upgrade or hotfix can change how an automated control calculates, validates or routes data even when the business logic looks the same. Teams often treat these as maintenance and keep the old baseline. Ask the application owner to classify each patch and release by its effect on financially significant logic, and reestablish the baseline when the classification shows a change that could affect the control.

Assuming prior-year evidence is accepted

Auditors use prior-year results to judge risk, but they still need current evidence that the control operated as described and that the description still matches the system. Reusing last year's screenshots, population reports or sign-off forms without checking their dates, the system version or the population completeness is a common cause of exceptions. Before the audit, have a second person re-review each reused item against current system data and record that review.

How DeployOpen helps prepare later-year ITGC evidence

DeployOpen can help an organization prepare the records that later-year ITGC testing depends on, but the organization still owns its controls and makes every decision about reliance. Engagements are fixed-scope: the systems, environments, control areas and deliverables are agreed in writing before work starts. DeployOpen plans, implements and hardens self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks, so the change tickets, approvals, access records and job logs that an auditor would sample stay under the client's control.

In practice, the preparation work tends to focus on the inputs that let management and the auditor justify lower testing. That can include configuring the platform so that change history links each change to a request, a reviewer and a test result, exporting user access reviews with dates and reviewer sign-off, and keeping a dated record of when an automated control's configuration last changed. Each of these supports the questions an auditor asks when deciding whether a baseline still holds. Whether a given record satisfies the auditor is for the auditor to decide, so the organization should confirm the required format and sample population with its auditor before the work is scoped.

DeployOpen does not issue audit reports, attestations or certifications, and it cannot promise that an auditor will reduce testing or accept any baseline. Those outcomes depend on the control design, the results of prior testing and the auditor's own risk assessment. Before engaging a partner, ask for the written scope, the named evidence artifacts, the retention approach and how the organization will hand records to its auditor. The organization should also decide internally who will review and approve the evidence, since that review is a management responsibility.

SOX ITGC testing in later years: rotation and reduced testing