Outsourcing SOX internal audit for ITGCs: what auditors accept

Can you outsource SOX internal audit for ITGCs and still rely on it?

Yes, an outside firm can test IT general controls for you, but the external auditor decides whether to use that work, and it does so based on the competence and objectivity of the people who did the testing. Management must assess internal control over financial reporting each year, and where the Section 404 auditor attestation applies, the auditor tests the same controls independently. Under PCAOB AS 2201, the auditor may use work done by internal auditors, other company personnel or third parties working under management's or the audit committee's direction, but it should not rely on testers with low objectivity regardless of skill, or low skill regardless of objectivity.

The answer depends on two things: the ICFR risk attached to each control and who actually performs the testing. Under paragraph 19 of AS 2201, the higher the risk of a control, the more of the work the auditor must perform on that control itself. SEC Release 33-8810 notes that internal auditors are normally the most objective evaluators, though other personnel may qualify depending on risk. For a high-risk access or program change control, ask the auditor early which testers it will accept, how it will check their work, and whether it will re-perform a sample. Also confirm that the people testing are not the people who designed or configured the control. The PCAOB Staff Audit Practice Alert No. 11 describes inspection findings where auditors relied on internal audit testing without a sufficient basis, especially in judgment-heavy areas.

Your organization owns its controls, and that ownership does not transfer to any outside firm. DeployOpen prepares systems, configurations and evidence for assessment, but it does not test controls for the external auditor and does not issue audit reports or attestations. Any independent testing you commission should be scoped in writing, with the tester's reporting line, deliverables and sample methods agreed before work starts, so the auditor can evaluate that work on its merits. Confirm these points directly with your audit firm before engagement, since its own independence obligations also limit what it can accept from you.

Objectivity and competence tests for outside testers

Before an auditor uses work done by an outside firm or internal team, it must clear two tests: the tester must be objective enough and competent enough. The cards below set out what each test looks at and what management should be able to show.

Objectivity relative to the control owner

Ask whether the tester reports outside the team that operates the control. A firm that configures an access platform and then tests its own configuration has a low degree of objectivity, however skilled it is. Check reporting lines, who approves test conclusions, and whether the tester ever designed or ran the control under review. Document each answer so the auditor can see the separation without asking.

Competence and relevant certifications

Competence means the tester understands the systems in scope, including the application, database and operating system layers that carry ITGCs, and the SOX testing method. Ask for named staff, their experience with similar financial systems, and any professional certifications they hold. A skilled tester who does not know the company's change or access workflows will produce weak evidence, so match the people to the systems.

Why internal auditors rank highest

SEC guidance says personnel whose core function is testing or compliance, such as internal auditors, are normally expected to be the most objective evaluators of controls. Other staff can qualify, but the company has to justify it. When an outside firm supports internal audit, the question is whether it works under internal audit's direction, which keeps the reliance chain clear.

ICFR risk sets how much reliance is allowed

The higher the risk a control addresses, the more of the testing the auditor must perform itself. Under AS 2201 this applies to the work the auditor relies on as well. For a low-risk ITGC, a moderately objective tester may be enough. For access to a general ledger or a period-end change path, expect the auditor to re-perform much of the testing, so plan the tester's scope around that.

Documenting tester independence

Keep a written independence statement for each tester and firm: who they report to, any prior role in the systems tested, and any engagement that would create a conflict. Update it when staffing changes mid-year. The auditor will ask for this file, and gaps in it lead to questions about whether any work can be used at all.

Quality of testing workpapers

Auditors judge outside work by its workpapers: the population tested, the sample selection, the attributes checked, the exceptions found and how they were resolved. Require that the tester's workpapers show what was tested, when, by whom and with which evidence. Thin conclusions without supporting detail are the kind of work auditors have found insufficient in inspections.

Why your audit firm cannot run the internal audit

Your external audit firm cannot perform the outsourced internal audit of your SOX ITGCs. SEC Rule 2-01(c)(4)(v) under Regulation S-X bars an auditor from providing outsourced internal audit services that relate to the audit client's internal accounting controls, financial systems or financial statements. IT general controls over financially significant applications sit squarely inside that description, so the bar applies to them. The rule carves out one case: the services are permitted only where it is reasonable to conclude the results will not be subject to audit procedures, which is a narrow exception and one that is hard to rely on when the same firm will then audit the controls it tested.

The practical consequence is that any outside firm you bring in to test ITGCs, walk through controls or prepare evidence for internal audit must be a different firm from your external auditor. This matters even when the audit firm's personnel are the most familiar with your environment. Before you sign a scope, ask your external auditor to confirm in writing which ITGC testing, documentation or design support it can perform, and which it cannot. Record the answer in your independence file, and confirm the analysis against your own facts with your auditor, since the classification of a specific service depends on the audit client, the systems involved and the reliance the auditor plans to place on the work.

The independence line also shapes how you describe the arrangement to the audit committee. An implementation or testing partner that is not your auditor can support management's evaluation, but management still owns the conclusion, and the auditor decides how much of that work it can use under AS 2201. If the partner's testing and the auditor's own procedures overlap in a way that makes it hard to show separation, plan for that early rather than discovering it during fieldwork.

Full outsourcing versus co-sourcing: which model fits

When the company already has an internal audit function, the usual question is capacity rather than ownership. Co-sourcing adds an outside firm to test specific ITGC areas, such as privileged access or change management, while internal audit keeps the program, the risk assessment and the reporting line to the audit committee. Under PCAOB AS 2201, the external auditor may use the work of internal auditors and of third parties working under management's direction, but only after judging their objectivity and competence.

What the outside firm tests: Specific ITGC areas agreed in writing, typically the testing of design and operating effectiveness for scoped applications, with workpapers that internal audit can review.
What management still signs off: The risk assessment, the control inventory, the selection of samples and the conclusion on whether deficiencies are material.
Reporting line: Findings flow through internal audit to management and the audit committee, not directly from the consultant to the business.
Independence check: Confirm the firm did not design or operate the controls it is testing, and that the external auditor has not outsourced internal audit work to the same firm under Rule 2-01.

Before work starts, ask the firm how it will document its testing so the external auditor can evaluate it against the objectivity and competence tests.

What inspections found about over-reliance on internal audit

PCAOB inspectors have found that some external auditors used internal audit's ITGC testing without a sufficient basis for doing so. Staff Audit Practice Alert No. 11, published by the PCAOB on October 24, 2013, reported this pattern, and the findings were not limited to low-risk areas. Reliance was found in higher-risk areas involving significant judgment, which is where an auditor should be doing more of the work personally. For a company that outsources or co-sources its ITGC testing, this means the firm's work will be read closely, and a clean internal audit report does not carry the auditor's reliance by itself.

The practical lesson is to assemble the file the auditor will need before they ask for it. For each tester, keep the scope memo, the population and sample support, the test steps performed, and the workpapers showing who reviewed them and when. Keep evidence of competence and objectivity as well: the tester's relevant credentials and experience with the platform, and confirmation that they did not design or operate the controls they tested. Confirm with your audit firm which of these records it will expect in the format it uses, because the standard tests competence and objectivity together, and gaps in either can cause the auditor to limit reliance.

Expect the closest scrutiny in the ITGC areas where judgment is heaviest and the risk is highest. Privileged access reviews are a common example, since the question is whether the population of privileged accounts was complete and whether the reviewer had enough detail to challenge each grant. Program change testing is another, where the auditor will want to see that the sample covered emergency and vendor-delivered changes, not only routine tickets. Before the fiscal year starts, ask your auditor which of these areas it plans to test directly, so that internal audit's work in those areas is documented to the level needed to support any reliance.

How a co-sourced ITGC engagement runs from scope to auditor reliance

The sequence turns an agreed set of ICFR-relevant IT general controls into tested, documented work that the external auditor can review and decide whether to rely on. Management stays accountable for the controls and the conclusions throughout. Each phase closes with a written output that both management and the auditor can point to.

Agree ICFR-relevant ITGC scope
Management, with the external auditor's input, defines which applications, databases, infrastructure and reports fall inside the ICFR evaluation, based on which IT-dependent controls support financial reporting risks. The partner and the auditor should not decide scope alone, because the company owns the risk assessment. The output is a signed scope memo listing systems, control areas (access, program changes, program development, computer operations) and the reasons each item is in or out.
Confirm tester independence and competence
Before any testing starts, management documents who will test, what they have done before, and how they are separated from the people who design or operate the controls they test. Each tester should be checked for competence in the technology in scope and for objectivity relative to the control owner. The output is a tester roster with an independence and competence statement that the external auditor can review.
Agree the testing approach and sample method
The tester, management and the auditor agree in writing how each control will be tested, including walkthrough steps, whether the test covers design, operating effectiveness or both, the population, and the sample method and size logic. Higher-risk controls, especially those involving significant judgment, should be tested in more depth. The output is a signed test plan that lets the auditor judge in advance whether the work is suitable for reliance.
Perform testing and document workpapers
The tester performs the walkthroughs and tests in the agreed plan, obtaining system-generated reports and checking their completeness and accuracy before relying on them. Every exception is recorded with its cause, and every test step leaves evidence that a third party could re-perform. The output is a set of workpapers that show what was tested, against which population, by whom and with what result.
Review results with control owners
The tester walks control owners through each exception and preliminary conclusion so that facts are confirmed before reporting. Owners may supply additional evidence or explain compensating controls, and the tester records whether the explanation changes the result. The output is a reviewed exception log with owner sign-off on the facts, while the evaluation conclusion stays with management.
Hand over workpapers for auditor reliance
The tester delivers the complete workpaper set, the test plan, the scope memo and the independence statement to management, which passes them to the external auditor. The auditor then decides how much of the work it can use, and for which controls, under the standards on using others' work. The output is a handover index and a written record of the auditor's reliance decisions, with any areas the auditor will test itself identified in advance.

What to confirm before you bring in an outside tester

An outside firm can test ITGCs only if the scope, reporting line, and standards for its work are fixed before fieldwork begins. Each item below is something to confirm in writing so the external auditor can decide how much of that work it can rely on.

Written scope tied to ICFR risk

Confirm which applications, databases, infrastructure and reports the tester covers, and link each to a financial reporting risk or an IT-dependent control. Management needs to evaluate only the ITGCs that support the proper and consistent operation of those controls, so a scope that includes operational efficiency work adds cost without helping the ICFR assessment. Ask for the scope in a document the auditor has reviewed.

Reporting line independent of owners

Confirm that the tester reports to someone who does not own the controls being tested, such as the audit committee, a CFO delegate outside the control chain, or the internal audit lead. A tester who reports to the team that runs the system cannot show the objectivity the auditor needs. Write the reporting line into the engagement letter so it survives staff changes.

Auditor's written view on reliance

Ask the external auditor, before testing starts, how it plans to use the tester's work and under what conditions. Auditors may use work from internal auditors, company personnel or third parties working under management's direction, but the decision is theirs. Get that view in writing, because a reliance plan agreed late often means the auditor retests the same controls.

Documented tester competence

Ask for evidence that the people testing each ITGC area have the skills for it, such as identity platform administration, change management or database controls. Competence and objectivity are tested separately, so a highly qualified tester with a conflict still fails the test. Keep résumés, certifications where relevant and a record of prior SOX ITGC work in the engagement file.

Defined sample and evidence standard

Agree on the population, sampling method, sample sizes and the evidence each test must retain before fieldwork starts. Specify how system-generated reports will be checked for completeness and accuracy, so the auditor can rely on them. Vague standards produce results that the auditor must redo, which adds time close to year end.

Remediation plan before year end

Confirm who owns each exception, the deadline to fix it and how retesting will prove the fix worked. Exceptions found late in the year leave little room for compensating controls or retesting, and higher-risk areas draw the most auditor scrutiny. Agree on an escalation path to the audit committee for any ITGC failure that could affect a material account.

Questions about outsourcing SOX ITGC internal audit

Will my external auditor accept testing done by an outside firm?

Yes, often, but only in part and only after the auditor has checked the work. Under PCAOB AS 2201, the auditor may use work performed by internal auditors, other company personnel and third parties who work under the direction of management or the audit committee. The auditor still decides how much reliance to place on that work, based on the risk of each control. The auditor will ask who directed the testing, how the tester was selected, what procedures were run, and whether the sample sizes and evidence support the conclusions. If the outside firm reports to management and follows a documented test plan, the auditor has a clearer basis to rely on it. Confirm the reporting line and test plan with the audit firm before the engagement starts, not after the fieldwork is done.

Can the company's audit firm perform the ITGC testing itself?

Generally no, at least not for the same company's internal accounting controls. SEC Rule 2-01(c)(4)(v) under Regulation S-X bars an auditor from providing outsourced internal audit services relating to the audit client's internal accounting controls, financial systems or financial statements, unless it is reasonable to conclude the results will not be subject to audit procedures. Because ITGC testing supports the reliability of financial systems, the audit firm generally cannot be the company's outsourced internal audit provider for those controls. Ask the audit firm to confirm in writing which services it may provide under its independence policies, and have counsel or the audit committee review that answer. Keep the testing function with a separate firm or with internal staff.

What does an outsourced ITGC test need from our own staff?

It needs named control owners who can explain how access, changes, development and operations actually work, and who can produce the underlying records on request. The tester will walk through each control, so system administrators, change managers and application owners must be available for interviews. Management also has to supply complete, unaltered populations, such as user access lists, change tickets and job logs, because the tester samples from them. Staff should document who approved each reviewed item and retain evidence for the period under test. Plan for this time up front. Delays in populations or missing approvals are a common reason testing slips past the planned window, and the company, not the outside firm, owns the controls being tested.

Can management keep ITGC testing in-house instead of outsourcing it?

Yes. SEC guidance in 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. Management can therefore test in-house if the people doing the testing are sufficiently objective and competent for the risk involved. The controls owner who runs a system should not be the only person who tests it. Many companies keep a small internal audit or compliance team that sets the test approach and reviews results, then bring in an outside firm for specialized ITGC procedures or for peak workload. Whichever model you choose, document the reasoning, because the auditor will assess it.

How do we tell whether an outside tester is objective enough?

Objectivity depends on reporting lines, independence from the controls being tested, and the tester's role, and competence depends on experience with the systems in scope. PCAOB AS 2201 says the auditor should not use the work of someone with a low degree of objectivity, regardless of competence, or someone with low competence, regardless of objectivity. Check whether the tester designed, implemented or operated any control in the test, whether they have a financial interest in the outcome, and who approves their findings. Ask for the test plan, the workpapers and the names and qualifications of the people doing the testing. Under AS 2201, as the risk associated with a control increases, the auditor performs more of that work itself, so a tester who cannot withstand scrutiny of high-risk controls adds little value.

What happens if the external auditor rejects the outsourced testing?

The auditor performs more of the work itself, which usually increases fieldwork, cost and the time needed before year end. Staff Audit Practice Alert No. 11 reported inspection findings where auditors used internal audit's testing without a sufficient basis, including in higher-risk areas involving significant judgment. Those findings show why auditors push back. The practical response is to find out early which specific tests or controls were not accepted and why, then fix the gap. Typical fixes include documenting the independence of the tester, expanding sample sizes, retaining the complete population, or reperforming selected tests. Ask the audit firm for its reliance criteria in writing before you commit to a testing approach, so the outsourced scope is built around what the auditor will accept.

Where outsourced ITGC testing usually goes wrong

Outsourced ITGC testing rarely fails because the testers lack skill. It fails on independence, on the terms under which the external auditor can rely on the work, and on the documentation and timing that let an auditor check it. Each card below names one failure point and the check that prevents it.

Testers report to control owners

When the people performing ITGC tests report to the IT leaders who run the systems being tested, the testing loses the objectivity the auditor needs. Under AS 2201, the auditor should not use work from people with a low degree of objectivity, however competent they are. Check the reporting line of every tester and confirm that results go to internal audit or the audit committee, not to the control owner. Confirm the reporting line in writing before fieldwork starts.

Reliance assumed without auditor agreement

Management sometimes assumes the external auditor will use the internal testing without first agreeing the approach. The auditor decides whether and how far to use others' work, based on its own risk assessment and its evaluation of the testers. As a result, work that looked sufficient to management may be redone in full. Agree the testing plan, sample sizes and evidence standards with the audit engagement team before testing begins.

Undocumented sample selection

Testers who choose samples informally, or who do not record how items were selected, leave the auditor unable to tell whether the population was complete. An illustrative case: a tester picks ten change tickets from the ones that were easy to find, and the auditor cannot determine whether the rest of the population was covered. Require a written population definition, a completeness check against the source system, and a record of the selection method for every sample.

Scope that misses IT-dependent controls

Internal testing often covers the applications people think of as financial, while the reports, interfaces and spreadsheets that feed financial controls fall outside the plan. Auditors test the IT general controls that keep automated and IT-dependent controls working, so a gap in scope becomes a gap in reliance. Map each key control to the systems, reports and data it depends on, then confirm each of those items is inside the testing scope.

Testing that lands too late

Testing completed after the auditor has finished its interim work, or in the final weeks before year end, gives the auditor no time to evaluate results or to ask for more. Higher-risk controls need more of the auditor's own work, so late results push the auditor toward independent testing and higher fees. Set interim and year-end deadlines with the audit team, and deliver workpapers in a form they can review without re-performing the test.

How DeployOpen prepares ITGC evidence for an outside test

DeployOpen plans, implements, configures and documents self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks, and prepares the systems and evidence that an internal audit function or external auditor may later test. Its role is to get the platforms into a state where the client's control owners can show how access, change and operations controls work. DeployOpen does not perform the auditor's role, does not issue reports or attestations, and cannot guarantee that an auditor will rely on any piece of work. Whether an auditor uses internal audit's testing depends on the auditor's own competence and objectivity assessment under AS 2201, not on who prepared the evidence. Most engagements are fixed-scope, so the written scope is where the reader should start. Before work begins, the scope should name the in-scope applications, the access, change and operations controls covered, the systems and environments involved, the evidence formats the client's auditors have accepted, and who on the client side owns each control and each review. It should also state what DeployOpen will not do, such as designing the company's control framework, selecting the internal audit sample, or signing off on whether a control operated. Ask for a written list of deliverables, including configuration baselines, runbooks, system-generated reports and the documentation needed to support information produced by the system (IPE) testing. At handover, the client should receive the evidence and documentation as its own records, stored in a location the control owners control. Confirm with the client's internal audit team and external auditor, before the engagement starts, the format and retention they expect. DeployOpen does not hold independence from the client's control owners beyond what the written scope states, so the client should keep management review, approval and reperformance of key reports in its own hands and should not treat DeployOpen's sign-off as evidence that a control operated.

Outsourcing or co-sourcing SOX internal audit for ITGCs