Relying on internal audit for SOX ITGC testing: how far

How far can the external auditor rely on internal audit for SOX ITGC testing?

The external auditor may use internal audit's ITGC testing, but only to the extent that the work is scaled to the internal auditors' competence and objectivity and to the risk of each control. Under PCAOB AS 2201, paragraphs 16 to 19, the auditor can use work performed by internal auditors and other personnel working under management's or the audit committee's direction, yet it still performs its own procedures on higher-risk controls. For a budget owner or audit committee asking whether an internal or co-sourced team can reduce external audit effort on ITGCs, the honest answer is that some reduction is possible on lower-risk controls, and very little is possible where risk is high or judgment is significant. Three things determine how much reliance is available. The first is control risk: as risk rises, the auditor must perform more of the work on that control itself. The second is the tester's independence from the control. The auditor should not rely on people with low objectivity regardless of their competence, or on people with low competence regardless of their objectivity. SEC guidance in Release 33-8810 treats internal auditors as normally the most objective evaluators, while noting that other personnel may be objective enough depending on ICFR risk. The third is the auditor's own evaluation of the testing it chooses to use, which is where inspection findings have repeatedly focused.

Management owns its controls, and the organization must not let the people who operate a control also serve as its independent evaluator. A co-sourced team that configures access rules, approves changes or administers the platform cannot test those same controls for management's 404(a) assessment without losing objectivity. Only the independent external auditor issues the attestation report under Section 404(b), so the practical question for the reader is which independent testing function, staffed with which skills, the auditor is willing to rely on. Before agreeing scope, ask the auditor in writing which ITGC testing it will consider for reliance, what competence and objectivity evidence it will request, and which controls it expects to test itself.

How control risk limits reliance on internal audit

The external auditor can use internal audit's ITGC work, but the amount it can rely on shrinks as control risk rises and as the work gets thinner. The five limits below set the boundaries that a management team or internal audit function should expect the auditor to apply.

Higher-risk controls need auditor testing

AS 2201 paragraph 19 says that as the risk associated with a control increases, the auditor must perform more of the work on that control itself. Controls over privileged access, emergency program changes and interfaces that feed journal entries carry more risk, so expect the auditor to reperform samples there rather than accept internal audit's results. Check your risk ranking of each ITGC and confirm which ones the auditor has marked for direct testing before planning internal audit's sample sizes.

Areas requiring significant judgment

Staff Audit Practice Alert No. 11 reported inspection findings where auditors relied on internal audit's testing without a sufficient basis, including in higher-risk areas involving significant judgment. Examples include access reviews where the reviewer must decide whether a role conflict is acceptable, and program change reviews that depend on a judgment about whether a change is significant. Ask the auditor which judgment areas it will test independently and document how internal audit's conclusions were reached in those areas.

Location coordination under paragraph B12

Paragraph B12 lets the auditor coordinate with internal audit's planned work at locations and reduce the number of locations it would otherwise test. This only helps when internal audit's plan covers the same locations, the same ITGCs and the same period as the auditor's scope. Compare the auditor's location list with internal audit's annual plan early, and agree in writing which locations and which control objectives each party will cover.

Co-sourced and third-party testers

Paragraph 17 extends reliance to people working under the direction of management or the audit committee, which includes co-sourced firms and other third-party testers. The direction must be real: the scope, sample selection and conclusions should be set by the company, not handed to a vendor and accepted without review. Confirm the engagement letter states who directs the work, who reviews the results and who can escalate exceptions.

Documentation that lets the auditor evaluate work

The auditor cannot rely on work it cannot inspect. Testers should keep test scripts, populations, sample selections, evidence references, reviewer sign-offs and reperformance notes so the auditor can judge the work's quality and extent. Ask the auditor which documentation it needs before testing begins, and check that a fresh tester could reperform a sample from the workpapers alone.

The auditor's evaluation of exceptions

Reliance does not stop at the tester's conclusion. When internal audit finds an exception, the auditor evaluates its nature, cause and effect on the control and on other controls, and decides whether it signals a deficiency or a broader problem. Exceptions in areas the auditor has already marked for direct testing are the most likely to be escalated. Confirm how exceptions are logged, who classifies them and how quickly the auditor receives them.

Why PCAOB inspections find over-reliance on internal audit

PCAOB inspectors have repeatedly found that external auditors relied on internal audit's ITGC testing without a sufficient basis for that reliance. Staff Audit Practice Alert No. 11, published October 24, 2013, reports these findings and notes that the problem appeared even in higher-risk areas where the control involved significant judgment. The lesson for management is that an auditor's permission to use internal audit's work is not a grant of reliance. The auditor has to build its own case for it, and the evidence for that case often depends on what internal audit gave it.

A sufficient basis, in practice, has three parts. First, the auditor evaluated the competence and objectivity of the internal audit staff who performed the tests, including whether they had the technical skills for the platform, such as the database or the change management tool, and whether they reported outside the team that owns the control. Second, the auditor reperformed or tested some of the underlying work, such as selecting a sample of user access reviews or change tickets and checking them against source records. Third, the auditor documented why it chose to rely on internal audit, how much weight it gave that work, and why the amount of its own testing was appropriate for the risk.

Management should plan for these questions before fieldwork starts. Ask the external auditor in writing which internal audit workpapers it expects to review, and confirm that the testing team can produce reperformance-ready samples, population completeness checks and tester sign-offs on request. Confirm the reporting line of every internal audit tester who touches a financially significant system. If any tester also administers that system or approves the changes they test, expect the auditor to discount the work heavily or perform its own testing instead.

Who can test ITGCs for management and for the auditor

Internal audit is usually the most objective internal tester because its core function is testing and assessing controls, and SEC guidance (Release 33-8810) normally expects such personnel to be the most objective evaluators. That objectivity is not automatic. Internal audit must have the competence to test IT general controls, and its work must be planned, documented and reviewed in a way the external auditor can rely on. The external auditor under PCAOB AS 2201 may use internal audit's work, scaled to its competence and objectivity and to the risk of each control. For higher-risk controls, the auditor performs more of the testing itself.

Objectivity: Confirm that internal audit reports to the audit committee and does not own, operate or design the ITGCs it tests.
Competence: Keep evidence of certifications, IT audit training and experience with the systems in scope.
Planning coordination: Retain the internal audit plan and any coordination with the external auditor on locations and sample sizes.
Work papers: Keep reviewed work papers that show procedures, samples and conclusions the auditor can reperform.
Scope limits: Record which controls internal audit did not test, since the auditor will test those itself.

Check whether the auditor has agreed in advance how much of internal audit's ITGC testing it will use, and document that agreement.

Why management's evaluators should not own the controls

A person who designs, implements, administers or approves a control cannot objectively evaluate whether that control works, and the external auditor will not give their testing much weight for that reason. The SEC guidance in Release 33-8810 says personnel whose core function is testing or compliance, such as internal auditors, are normally expected to be the most objective evaluators, and the PCAOB's AS 2201 says the auditor should not rely on people with a low degree of objectivity, however capable they are. In practice, the common failures look like this: an IT security administrator reviews the access list for the ERP system they maintain, a change manager approves the production releases they also scheduled, or an implementation partner tests the interface it configured the week before. Each of these tests confirms the builder's own assumptions, so the result carries little weight.

An implementation partner that prepares systems, configurations and evidence is doing valuable work, but that work is not independent testing. The partner's engineers are part of the control environment when they build the access model, write the change workflow or populate the reconciliation reports. If the same team later fixes a deficiency the auditor found, the fix is itself a control change that someone must evaluate, and the people who made it are the wrong people to evaluate it. Ask your team and any outside firm to state in the statement of work which tasks are build, which are operate, and which are test, and who signs off each. Where a firm both remediates and tests the same area, plan for management or internal audit to retest the remediated control before the auditor relies on it.

Put the role separation in writing before fieldwork starts. A short RACI-style matrix for each ITGC area can name the control owner, the operator who performs the control, the reviewer who approves the output, and the tester who evaluates it. Confirm with your external auditor which tester roles they will accept for each area, because their acceptance depends on the competence and objectivity they assess for that person. Keep the matrix with your documentation, update it when personnel or providers change, and check that no individual appears as both operator and tester for the same control.

How internal audit work moves into the external audit

This sequence shows how internal audit's ITGC testing becomes evidence the external auditor can rely on, from the agreed scope through to the auditor's own adjusted procedures and management's 404(a) assessment.

Agree scope with the external auditor and audit committee
Management, the external auditor and the audit committee agree which ITGCs, applications, databases, infrastructure and locations internal audit will test, and which the auditor will test itself. The auditor sets its expectations for the work in writing before internal audit starts. The output is a signed-off scope memo that names the controls, the period covered and who owns each test. Internal audit should not begin fieldwork until this memo exists.
Evaluate internal audit's competence and objectivity
The external auditor assesses whether the internal audit staff who will perform the tests have the technical skills for IT controls and whether they sit outside the teams that operate those controls. Under AS 2201, the auditor should not rely on work from people with low objectivity regardless of competence, or low competence regardless of objectivity. Reporting lines, prior roles, training records and any role in designing or running the controls are reviewed. The output is the auditor's documented conclusion on each tester, which sets how much reliance is possible.
Plan which controls and locations to rely on
The auditor decides which internal audit tests it can use and how much, based on the risk of each control. As risk rises, the auditor performs more of the work on that control itself. For multi-location environments, the auditor can coordinate with internal audit's planned location work and reduce the number of locations it would otherwise test. The output is a reliance plan listing each control, the planned reliance level and the auditor's own procedures for higher-risk items.
Perform internal audit testing with documented workpapers
Internal audit executes the agreed tests, such as inspection of change tickets, access review sign-offs and job logs, and records each test in workpapers. Each workpaper should state the control objective, the population, the sample selected and how it was chosen, the evidence examined, the exceptions found and the conclusion reached. Exceptions are escalated to management and the auditor as they arise, not held until the end. The output is a complete set of workpapers that another person could follow without asking the tester.
Reperform or review selected items
The external auditor reviews internal audit's workpapers and reperforms a selection of tests, weighted toward higher-risk controls and areas involving significant judgment. Staff Audit Practice Alert No. 11 reported inspection findings where auditors used internal audit's testing without a sufficient basis, so this step is where that gap is closed. The auditor checks that the sample and evidence support the stated conclusion. The output is the auditor's review notes and any reperformed results, with differences resolved before the auditor relies on the work.
Document the auditor's conclusion and adjust its own tests
The auditor records how much of internal audit's work it relied on, for which controls and at which locations, and why. Where internal audit's work is accepted, the auditor may reduce the nature, timing and extent of its own tests. Where the work is not sufficient or the risk is high, the auditor performs additional procedures itself. The output is the auditor's ICFR testing plan and workpaper conclusion for each ITGC, which the audit committee can review.
Coordinate with management's 404(a) assessment
Management uses internal audit's results as one input to its own annual assessment under Section 404(a) and Rule 13a-15, and it must still reach its own conclusion on the ITGCs. Management confirms that its evaluation is supported by evidence and that the testers were independent of the controls they assessed. Any deficiency found by internal audit is classified and tracked through the remediation process. The output is a management ICFR evaluation file that references internal audit's workpapers, the auditor's conclusions and the status of each open deficiency.

Which testing model fits which control risk

This table compares three ways the external auditor can divide ITGC testing between internal audit and its own team. Read each row as a decision: the fit depends on how much judgment the control involves, how risky it is, and whether internal audit has been tested for competence and objectivity. The main takeaway is that reliance drops as risk rises.

Testing model	When it fits	What the auditor typically needs to see	Main risk
Full reliance with reperformance	Lower-risk, largely automated controls where internal audit's competence and objectivity have been assessed and the work is documented in enough detail to reperform.	Evidence that internal audit is competent and objective, its workpapers and sample selection, and the auditor's own reperformance on a sample of items.	Reliance on testing that was not planned, documented or sampled with enough rigor, which PCAOB inspections have cited as insufficient basis.
Shared testing by risk	Mixed control populations where internal audit covers lower-risk controls and the auditor tests higher-risk controls itself. This is the common model when risk varies across the ITGC areas.	A risk-based allocation of controls, evidence that internal audit's work covers the controls it is credited with, and the auditor's own tests on the higher-risk items.	Gaps at the boundary between the two groups, or a risk rating that understates a control's exposure, so a higher-risk control is left to internal audit alone.
Auditor-led testing	Controls that involve significant judgment, controls with prior deficiencies or material weakness history, and controls over high-risk areas such as privileged access to financially significant systems.	The auditor's own walkthroughs, design and operating effectiveness tests, and evidence drawn directly from systems and records rather than from summaries.	Higher audit effort and cost, and friction if management expected internal audit to carry the work. Confirm the plan early with the audit team.
Coordination on locations and timing	Multi-location environments where internal audit already plans testing at several sites or units.	Internal audit's planned work by location and period, and evidence that the auditor reviewed it before reducing its own coverage.	Reduced location coverage based on another team's plan that changes mid-year without the auditor being told.
Objectivity of the evaluator	Any model in which the tester also operates, configures or approves the control being tested.	Documented separation between control owners and evaluators, and an explanation of how any personnel with dual roles were judged objective enough for the ICFR risk.	Self-review. Personnel whose core job is testing are normally expected to be the most objective evaluators, so dual-role testers add little independent assurance.
Competence of the internal audit team	Whenever internal audit or a co-sourced firm performs ITGC testing that the auditor plans to use.	Qualifications of the testers, their experience with the specific platforms, and the review process over their work.	Testers with general audit skills but limited knowledge of the application, database or cloud platform under test.

What internal audit's ITGC workpapers must show before the auditor relies on them

An external auditor can use internal audit's ITGC work only after it can see how that work was scoped, performed, reviewed and kept. The cards below cover the workpaper items an auditor checks, and what management should confirm with the auditor before fieldwork begins.

Documented scope and risk basis

The workpapers should state which applications, databases, infrastructure and locations were tested, and why each falls inside ICFR scope. Under AS 2201, the auditor scales reliance to the risk of each control, so a scope memo that ties each tested control to a financial reporting risk is the first thing to check. Ask the auditor whether it accepts the risk ratings used and whether any high-risk control is excluded from internal audit's work.

Testing procedures and populations

Each test needs a written procedure that says what was inspected, inquired about or reperformed, and the population it was drawn from. An auditor cannot judge the quality of a sample without knowing the population, such as the full list of users with production access or every change ticket closed in the period. Confirm that the population was complete and accurate, and that the report used to produce it was itself tested.

Sample selection and exception handling

Workpapers should show how samples were selected, whether selection was random or targeted, and how many items were tested. Every exception needs a recorded cause, an assessment of whether it indicates a control failure, and a follow-up result. Auditors commonly reject reliance when exceptions were closed without analysis, so ask for the exception log before fieldwork and check that each one has a conclusion.

Evidence retained for reperformance

The auditor must be able to reperform internal audit's test from the workpapers alone. That requires the screenshots, system reports, query parameters, ticket references and approval records themselves, not only a note that the test passed. Confirm the retention period and storage location with internal audit, and check that evidence from system reports includes the date, the parameters and the person who ran the report.

Reviewer sign-off

Each workpaper should show who prepared it and who reviewed it, with dates for both. Review should be by someone above the preparer who can judge whether the conclusion follows from the evidence. Unsigned or self-reviewed workpapers are a frequent reason auditors decline to rely on the work, so confirm the review chain and the reviewer's role with the auditor before fieldwork.

Dated independence statement

Under SEC guidance, personnel whose core function is testing or compliance, such as internal auditors, are normally expected to be the most objective evaluators. The workpapers should include a dated statement that the testers do not design, operate or approve the controls they test. Where a co-sourced firm or an internal team also helps with remediation, the statement should say so, because that overlap can lower the objectivity the auditor is willing to accept.

Where an implementation partner fits and where it cannot

An implementation partner such as DeployOpen can help prepare the systems, controls and evidence that internal audit or a co-sourced team later tests, but it cannot be the independent tester of controls it designed, configured or documented. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside the client's own infrastructure, and it prepares evidence for assessments. It does not issue audit reports, provide an attestation or certify anything. Only the external auditor decides whether management's evaluators, internal audit or a co-sourced team can be relied on, and that decision rests on the competence and objectivity of the people doing the work. A partner that built an access review workflow is not objective about whether that workflow operates, so its staff should not be the testers for those controls.

In practice, the useful boundary is between preparing artifacts and performing the test. A partner can help a co-sourced team pull user listings, change tickets, approval records and backup logs in a consistent format, and it can document how each system produces that data. The co-sourced testers still select samples, compare evidence to the control description, and record their own conclusions. Before work starts, ask the auditor in writing which artifacts it will accept as coming from the system of record and which testing it will perform itself, because the answer determines how much of the partner's output can be used at all.

Fixed-scope statements of work should say this plainly. Name each control and system in scope, list the deliverables the partner will produce (for example, configuration baselines, evidence extraction scripts or narrative drafts), and state that the organization owns its controls, its conclusions and its management assessment. Add that the partner will not perform tests on controls it implemented and that no report or attestation is issued by the partner. Confirm with the external auditor, and with the organization's own audit committee, that the planned split of work is acceptable before the engagement begins, since the auditor's reliance decision cannot be settled by a contract clause alone.

Common questions about relying on internal audit for SOX ITGCs

Can the external auditor use internal audit's ITGC testing at all?

Yes, but only in part and only after the auditor checks the work. Under PCAOB AS 2201 (paragraph 17), the external auditor may use work performed by internal auditors, other company personnel and third parties working under the direction of management or the audit committee. That permission does not transfer responsibility. The auditor still forms its own opinion, and the amount of reliance depends on the competence and objectivity of the people doing the testing and on how risky each control is. Internal audit's testing is one input the auditor evaluates, not a substitute for the auditor's own procedures.

Does relying on internal audit reduce SOX audit fees?

It can reduce the auditor's testing hours, but the size of the reduction depends on the controls, the risk and the quality of the internal audit work, and no supplied source quantifies it for ITGCs. Reliance is limited where the control is high risk, because under AS 2201 (paragraph 19) the auditor must perform more of the work itself as risk rises. Fee impact also depends on how much the auditor must re-perform to test the work. The SEC's 2020 estimate of about $210,000 per year (Release 34-88365) applies to issuers newly exempt from the Section 404(b) auditor attestation. It answers a different question, the cost of no attestation at all, and should not be used to predict the savings from internal audit reliance. Ask the auditor to state in writing which controls it plans to rely on and how it will test that work.

Who decides whether the external auditor relies on internal audit?

The external auditor decides, based on its own risk assessment and its evaluation of the internal audit function. Management and the audit committee can support the decision by giving the auditor access to plans, workpapers and staff, and by making sure internal audit reports to the audit committee. Under AS 2201 (paragraph 18), the auditor should not use work from people with a low degree of objectivity regardless of their competence, or from people with a low level of competence regardless of their objectivity. Management does not get to declare reliance. It can, however, decide who performs the testing and how that team is structured, which shapes what the auditor can accept.

Can a co-sourced firm count as internal audit for reliance?

A co-sourced team can be treated like internal audit when it works under the direction of management or the audit committee, which AS 2201 (paragraph 17) recognizes as a basis for reliance. The question is therefore less about the label and more about who directs the work, who reviews it and whether the people involved are objective about the controls they test. An outside firm that also designed, implemented or operated the controls it later tests will struggle to show objectivity. Confirm the reporting line, the engagement letter and whether the same people have worked on remediation before accepting that their testing counts. Ask the external auditor early whether it will accept that structure.

What happens if the external auditor finds internal audit's testing insufficient?

The auditor does not rely on that testing for the affected controls and performs its own procedures instead, which generally means more audit effort and a higher fee. Staff Audit Practice Alert No. 11 reported PCAOB inspection findings where auditors used internal audit testing without a sufficient basis, including in higher-risk areas that involve significant judgment. Those findings are the reason auditors document their evaluation of competence and objectivity. Where testing has gaps, the company may also need to fix documentation, extend sample coverage or retest before year end. Ask the auditor what evidence it will need to accept the work, and resolve gaps before fieldwork rather than during it.

What must the company provide so the auditor can rely on internal audit?

The company needs to give the auditor enough information to evaluate both the people and the work. In practice that means: - Written internal audit charter, methodology and reporting line to the audit committee - Evidence of the testers' training, experience and independence from the controls they test - Test plans, scripts, sample selections, workpapers and review sign-offs for each ITGC - Records of how exceptions were raised, tracked and closed - Access for the auditor to re-perform selected tests and to discuss results with the testers Confirm with the external auditor which items it expects, because the sufficiency of each depends on the controls and risk involved.

Should management's evaluators be independent of the controls they test?

Yes, because objectivity is what gives testing its weight. SEC guidance (Release 33-8810) says personnel whose core function is serving as a testing or compliance authority, such as internal auditors, are normally expected to be the most objective evaluators of controls, though other personnel may be objective enough depending on ICFR risk. The people who administer an access control, approve a change or run a backup are poor evaluators of that same control because they have a stake in its result. Keep the testing function separate from the control owners where possible, and document why any other evaluator is objective enough for a given control.

How DeployOpen prepares evidence for an independent reliance decision

DeployOpen's part in an internal audit reliance decision is to make the work easy to inspect, not to make the reliance decision itself. Before work starts, the scope is written down: which applications, databases, infrastructure components and reports are covered, which ITGC areas are in and out, and which deliverables are handed over. That written scope is what internal audit or the external auditor compares against their own risk assessment, so it should name the systems and control objectives in plain terms rather than general descriptions of security practice. DeployOpen is not an audit firm. It does not issue audit reports, attestations or opinions on ICFR, and it does not replace the independent auditor, who alone decides whether and how far to use anyone else's work.

DeployOpen keeps the people who configure and build a control separate from the people who prepare test evidence for it. If the same engineer implements a change control workflow and then samples its own changes, the evaluator is not objective, and PCAOB AS 2201 paragraph 18 would give that work little weight whatever its quality. In practice this means the implementation team delivers the control design, configuration exports and change records, while internal audit or a co-sourced tester performs the walkthroughs, selects samples and documents conclusions. Ask any partner to show who signed each workpaper and whether that person had any role in operating the control under test. Confirm the separation in the written scope, not only in conversation.

The evidence package is built to be re-performed. DeployOpen can prepare workpaper templates that record the control objective, the population, the sample selection method, the source system and query used, the reviewer and the date. Documentation covers control narratives, the matrix linking each control to its risk, and handover notes that explain how evidence is generated. Using this work does not guarantee that the auditor will rely on it. Reliance depends on the competence and objectivity of the people who did the work, the risk of each control, and the auditor's own testing. Organizations should ask their auditor early which templates and evidence formats they accept, and confirm with internal audit how much of its testing it expects to rely on before the engagement begins.

Relying on internal audit for SOX ITGC testing