Can your external auditor help with SOX ITGCs without losing independence?
Your external audit firm can test IT general controls and communicate what it finds, but it may not design, operate or monitor them, outsource internal audit work over your financial systems, or act as part of management, unless the results of that work will not be subject to audit procedures. The limits come from SEC independence rules in Rule 2-01(c)(4) of Regulation S-X, which apply to the same firm that signs your Section 404(b) attestation. Whether a specific service crosses the line depends on what the firm would actually do, so the question to ask is not whether the firm can help with ITGCs in general but which task, performed by whom, is being proposed.
Management keeps the responsibility throughout. Your company owns its controls, performs the management assessment required by Section 404 under 15 U.S.C. 7262, and decides how deficiencies are remediated and disclosed. Only the independent auditor issues the attestation report, and PCAOB AS 2201 requires management to represent in writing that it did not use the auditor's procedures as part of its own assessment. A firm that has designed the controls or built the evidence it later tests cannot give that independent view, so the independence question has to be settled before the engagement starts.
Before you sign anything, ask the audit firm to put each proposed task in writing and check it against Rule 2-01(c)(4) with your audit committee and counsel. Confirm who designs, configures, operates and reviews each control, and who prepares any system report the auditor will rely on. If the firm is not permitted to do a task, a separate consultant or co-sourced internal audit team can often do it, provided that team is not the auditor. The rules and their application are technical, so confirm the final position with your audit committee, counsel and the firm's independence group.
Which auditor-side ITGC activities are permitted, restricted or prohibited
Under the SEC's auditor independence rules in Regulation S-X Rule 2-01, an accountant is not independent if it designs or implements a system that aggregates source data underlying the financial statements, unless the results will not be subject to audit procedures. For ITGC work, this means the audit firm should not configure the financial application, design the access model for the ledger, or build the change workflow that management is expected to own. Lighter support, such as explaining a control concept or reviewing management's design, is usually treated differently from building the system itself, but the line depends on the specific facts.
- Usually permitted: Explaining control principles, reviewing management's design documents and giving feedback that management evaluates.
- Case-by-case: Advice that shapes system configuration or data flows, where the firm's involvement could be read as design work.
- Prohibited: Designing or implementing a system that aggregates financial source data, unless its output will not be subject to audit procedures.
- Practical check: Ask whether management, not the firm, made and documented each design decision.
Confirm the specific engagement with your audit committee and the auditor's independence team before any design support begins.
Rule 2-01 also says an accountant is not independent if it operates or supervises an audit client's information system. For ITGCs, that covers running the application, granting or approving user access, administering privileged accounts, or running production jobs. Management must keep these functions. Performing them makes the firm part of the control environment it is supposed to test, which compromises its ability to report on that environment.
- Usually permitted: Providing read-only reports or extracts that management uses in its own review, provided management performs the review.
- Case-by-case: Occasional technical help during an incident, where the firm's role is limited and documented.
- Prohibited: Operating the system, approving access requests, creating or changing user accounts, or running scheduled financial processing.
- Under Rule 2-01(c)(4)(vi): Acting as a director, officer or employee, or performing decision-making, supervisory or ongoing monitoring functions for the client, is also barred.
Ask the auditor to identify which access administrators sit at the firm, if any, and confirm the answer in writing with your audit committee.
Rule 2-01(c)(4)(v) bars an auditor from providing outsourced internal audit services related to internal accounting controls, financial systems or financial statements, unless it is reasonable to conclude the results will not be subject to audit procedures. Many companies use a separate firm for ITGC testing precisely to avoid this issue. Whether the external auditor may perform any internal audit work on ITGCs depends on how closely that work relates to financial reporting controls and whether the results will be re-tested by the audit team.
- Usually permitted: Using a firm other than the audit firm for ITGC testing, with management owning the internal audit function.
- Case-by-case: Limited internal audit tasks on non-financial areas, where the work does not touch ICFR.
- Prohibited: Outsourcing internal audit of financial systems or controls to the audit firm, where results would not be re-tested.
- Documentation: Keep a written independence analysis that shows why any shared work is acceptable.
Request that analysis from the auditor before engaging anyone for internal audit support.
External auditors test ICFR under AS 2201 and must understand the ITGCs that support automated controls. Auditors may test controls, read management's documentation and communicate deficiencies. What they may not do is perform management's evaluation for it. AS 2201 requires management to represent that it did not use the auditor's procedures as part of the basis for its own ICFR assessment and that it disclosed all deficiencies it identified. Management's assessment must stand on its own evidence.
- Usually permitted: Testing controls as part of the audit, reporting deficiencies and discussing observations with management and the audit committee.
- Case-by-case: Sharing test scripts or results that management then reuses, which may blur the line between auditor work and management's assessment.
- Prohibited: Using the auditor's procedures as management's basis for its own ICFR conclusion.
- Representation: Management must sign that it disclosed all identified deficiencies, so track them internally from the start.
Confirm the representation process and evidence ownership with the auditor's independence team before fieldwork begins.
When an ITGC fails, management must decide how to fix it, evaluate the impact on IT-dependent controls and disclose deficiencies. An auditor may explain the deficiency and the audit standard that applies, but designing the remediation or operating the fix moves into management functions or system design. Management also maintains responsibility for controls over outsourced operations, even when it relies on a service auditor's report. The auditor's role after a failure is to evaluate and report, not to fix.
- Usually permitted: Explaining what the deficiency means for the audit, the severity question and the evidence the auditor would need.
- Case-by-case: Feedback on a remediation plan drafted by management, where the auditor avoids making decisions.
- Prohibited: Designing or implementing the remediation, or taking on any decision-making or ongoing monitoring role.
- Timing: Remediation must be owned by management and evidenced before year end to support conclusions.
Ask the auditor to put in writing which remediation discussions are advisory and which would require a separate independence review.
Why management must represent it did not rely on the auditor's procedures
Under PCAOB AS 2201, paragraph 75, the external auditor requires written representations from management, and two of them matter most for ITGC work. First, management states that it did not use the auditor's procedures as part of the basis for its own ICFR assessment. Second, management states that it disclosed to the auditor all deficiencies it identified. Management signs these statements as part of the year-end file, so the representation is a formal statement by the company, not a note from the audit team. If the company's own assessment of access or change controls leaned on work the audit firm performed, the representation would be inaccurate, and the auditor's reliance on that work would be compromised.
The risk is sharpest when the audit firm, or a party it affiliates with, has touched the ITGCs. The SEC independence rules already limit what the auditor may design, operate or monitor, so any ITGC testing the company wants from its audit firm is constrained before the representation even comes up. Management should therefore decide, before fieldwork starts, which party performs its own assessment testing, and document that the testers did not draw on the auditor's walkthroughs, samples or workpapers. A common failure is a control owner who says the access review was "already checked by the auditors" and records that as the basis for the conclusion. Confirm with the audit committee and the external auditor exactly which materials may be shared, and in what direction.
To show its assessment was independent, management should keep a dated record of its own testing plan, the populations and samples it chose, the testers' names and roles, and the evidence each tester reviewed. Where a consultant or co-sourced internal audit team performs the work, keep the engagement letter that sets the scope, and a file note stating which auditor deliverables were and were not provided to that team. Keep the deficiency log that feeds the disclosure representation, with the date each item was identified and how it was communicated to the auditor. Ask the audit firm to confirm in writing what it considers acceptable reliance on management's work, since the answer determines how much of this file the auditor will read.
Common requests to the audit firm and how to answer them
Finance and IT leaders often ask their external auditor for help that feels like normal support but falls inside the independence line. The cards below cover common requests, the likely answer under SEC independence rules, and the alternative that keeps management in control and the audit intact.
Configuring access rules in systems
Asking the auditor to set up role assignments, segregation of duties rules or approval workflows in an ERP or identity platform is a request to design or operate a financially significant system. Under Rule 2-01(c)(4)(ii) of Regulation S-X, an auditor that operates or supervises an audit client's information system is not independent unless the results will not be subject to audit procedures, and that exception rarely fits access configuration. The safer path is for management's own administrators to make the change, with an independent consultant or co-sourced reviewer checking the design. Ask who made each change and who approved it, and keep the request and approval record.
Running quarterly access reviews
Asking the auditor to perform the periodic user access review means the firm would be performing an ongoing monitoring or control function for the client. Rule 2-01(c)(4)(vi) treats any decision-making, supervisory or ongoing monitoring function as a bar to independence. The review itself is a management control, so the business owner of each application should approve the access, and an independent party can test whether the review was complete and accurate. A useful check is whether the reviewer can show the population they reviewed and the changes made after the review.
Taking over internal audit testing of ITGCs
Asking the audit firm to run the internal audit function's ITGC testing, or to test controls it helped design, collides with the bar on outsourced internal audit services related to internal accounting controls and financial systems under Rule 2-01(c)(4)(v). The exception applies only if the results will not be subject to audit procedures, which is hard to show when the same firm is also testing those controls for the attestation. A co-sourced internal audit firm that is separate from the external auditor is the usual alternative. Confirm that the firm's testers did not design the controls they test.
Writing remediation plans for failed controls
Asking the auditor to draft the remediation plan for a deficient change or access control puts the firm in a management role, because management owns the decision on how to fix a deficiency. The auditor can communicate deficiencies it found, but management must evaluate them, decide the fix and document the plan. An independent consultant can draft the plan as a proposal for management to approve, and management should record why it chose that fix. Ask for the root cause analysis, the owner, the target date and the test that will show the fix works.
Reviewing a readiness gap assessment
Asking the auditor to review or sign off on a readiness gap assessment prepared by a consultant can be acceptable as a general accounting or ICFR discussion, but the auditor should not design the controls or decide the gaps. The gap assessment is management's work product, and any advice the auditor gives must not become part of management's basis for its own ICFR assessment, which PCAOB AS 2201 requires management to make without relying on the auditor's procedures. Keep the auditor's comments in writing, separate from the consultant's deliverables, and make sure management owns the final assessment.
Preparing a service auditor report on a provider
Asking the company's own audit firm to prepare a SOC 1 Type 2 report on a cloud or payroll provider is a request the SEC staff addressed directly. Management may rely on a service auditor's report even when the same firm audits the registrant, but not when the registrant's own audit firm was engaged to prepare that report. Management still must assess controls over outsourced operations and map the provider's controls to its own. Ask the provider's independent service auditor for the report, then have management or an independent consultant review its scope and exceptions.
What management must keep in-house even with outside help
Management owns the ICFR assessment, and no outside firm can take that over. Under Rule 13a-15(c), management must evaluate internal control over financial reporting as of each fiscal year end against a suitable, recognized framework, and the evaluation is management's report, not the auditor's. That means management decides which IT general controls are necessary for the proper and consistent operation of the controls that address financial reporting risks, evaluates whether each one operates, classifies deficiencies, and decides what is disclosed. A consultant or the audit firm can prepare the analysis, but the people who sign the report and the certifications must be employees who own the conclusion. Confirm with your auditor, in writing, which of these decisions they expect management to document and approve directly.
Management also keeps responsibility for controls over outsourced operations. When a cloud provider, SaaS vendor or managed service runs part of a financially significant system, management still has to assess the controls over that work. SEC staff FAQ Question 8 is explicit that relying on a service auditor's report does not remove this duty. The reliance route has a hard limit: management may use a Type 2 service auditor's report even when the same firm audits the company, but not when the registrant's own audit firm was engaged to prepare that report. Before you rely on any provider report, check who engaged the service auditor, confirm the report covers the period and controls you need, and record the gap analysis for user entity controls that the provider expects you to operate.
Management must also make the representations the auditor will request. Under AS 2201, management provides written representations, including that it did not use the auditor's procedures as part of the basis for its own ICFR assessment and that it disclosed all deficiencies it identified. Those statements only hold up if your team can show how it tested the controls independently of the auditor's work. Keep a dated record of who performed each test, what evidence they used, and who reviewed the results, and make sure the people signing the representations have read the deficiency log. An implementation partner's work can support this record, but the representations themselves stay with management.
What an implementation partner can take on without touching independence
An implementation partner such as DeployOpen can prepare the systems, documentation and evidence that support management's ICFR assessment. Management owns every control and decision, and the independent auditor alone issues the attestation, so each card below marks where partner work stops and management's own responsibility begins.
Scoping inputs
The partner can compile the inventory management needs to decide which applications, databases, infrastructure components and locations fall within ITGC scope. This includes mapping which systems feed financial reports and which automated controls depend on them. Management still makes the scoping decision and documents the rationale, and the auditor evaluates that decision independently. Ask for the inventory format and who signs off on the final scope list.
Control design documentation
The partner can draft narratives, control matrices and process flows describing how access, program change, program development and computer operations controls are meant to work. Drafts give control owners a starting point they must review, correct and adopt. Management remains accountable for the design, and the documentation should describe what the organization actually does, not what a template assumes. Confirm that control owners approve each document before it is used as evidence.
System configuration and hardening
The partner can configure in-scope platforms so that controls operate as documented, such as enforcing single sign-on, enabling audit logging, restricting administrative roles and setting approval steps in change workflows. Configuration work creates the conditions for evidence, but it must be performed under management's direction and recorded in change tickets. Any setting the partner changes becomes part of the system that management must test and maintain.
Evidence collection and organization
The partner can build repeatable routines that pull access review reports, change approvals, job logs and backup records into a consistent folder structure keyed to each control. Good organization lets management and the auditor trace a control from its design to its operating evidence. Ask how the partner records the source, date and parameters of each system report, because auditors test whether those reports are complete and accurate before relying on them.
Readiness testing support
The partner can run dry-run walkthroughs and sample selections to find gaps before the external auditor arrives, then report exceptions to management. Readiness testing is a preparation step and does not replace management's own evaluation or the auditor's testing. The partner should not perform the management monitoring function or make decisions on remediation. Confirm in writing that findings go to management and that the partner will not decide which deficiencies to disclose.
How to decide whether a task can go to your auditor
This sequence turns a vague question ("can our auditor do this?") into a documented decision that management owns, that the audit committee can review, and that the independence team has assessed in writing before any work starts.
Define the task and the control it supports
Write down the specific task in plain terms, such as configuring access roles in a financial application, drafting a change-approval procedure, or testing a user access review. Then name the SOX ITGC it supports, for example the access or program change control that protects an IT-dependent financial reporting control. Management, usually the control owner with the CFO or controller, signs the task description. The step is complete when the task and its control are written in one sentence each and the reviewer can see which financial reporting risk the control addresses.
Confirm who will perform the work
Establish whether management, its own staff, a separate implementation partner or another third party will carry out the task, and who will decide on the outcome. Separate the activity from the judgment: operating a system, designing a control, approving a configuration and monitoring the result each raise different independence questions. The output is a short responsibility record that names the performer, the decision owner and the person who will accept results, so no role is left implied.
Request a written independence assessment
Send the task description and responsibility record to the audit firm's independence team and ask for a written view on whether the firm may perform the work. Ask specifically whether the task would make the firm responsible for operating or supervising the information system, designing or implementing a system that aggregates source data, performing outsourced internal audit over internal accounting controls, or taking part in management decisions. The step is complete when you hold a signed response that states the conclusion and the conditions attached to it.
Confirm the conditions in the response
Read the firm's answer for any condition, such as the work being limited in scope, performed by a different team, or not being subject to audit procedures. Confirm with your own team that the actual work matches the scope the firm reviewed. If the scope changes, return to the first step and repeat the request. The output is a checked list of conditions with an owner for each one, so the answer stays valid as the engagement evolves.
Document the decision for the audit committee
Prepare a decision memo that lists the task, the performer, the independence response and the conditions, and the management rationale for the outcome. Present it to the audit committee and record its review in the minutes. Management should also be ready to make the representations the external auditor will request, including that it did not use the auditor's procedures as part of the basis for its own ICFR assessment. The step is complete when the committee has reviewed the memo and the decision is filed with the engagement records.
Assign a separate reviewer for later testing
If the task produces a control or evidence that will later be tested, name a reviewer who did not perform or design that work to evaluate it. This preserves the objectivity needed when the control is assessed, and it keeps the audit firm out of any management function. Record the reviewer's name, the test scope and the date of the review in the control documentation. The output is a documented evaluator who is independent of the work they assess.
Record the outcome for each assessment cycle
Repeat the sequence whenever the task, performer or scope changes, and review existing decisions at each fiscal year end when management evaluates ICFR. Keep a single register of decisions with the memo, the independence response and the reviewer for each item. The register shows the auditor and the audit committee that the boundary was set deliberately and maintained over time, rather than assumed at the start of the engagement.
Questions buyers ask about auditor help with SOX ITGCs
Can our external auditor help us design SOX ITGCs?
Generally no, not in a way that goes into the controls the auditor later tests. Under Regulation S-X Rule 2-01, an accountant is not independent if it designs or implements a system that aggregates source data underlying the financial statements, unless the results will not be subject to audit procedures. Designing your access or change controls is a management decision, and the auditor cannot make it for you and then audit the result. Ask your audit firm in writing which pieces of design advice it considers permissible, and involve your audit committee before any engagement starts.
Can the audit firm run our user access reviews for us?
No. An access review is a management control with an ongoing monitoring element, and Rule 2-01 treats performing decision-making, supervisory or ongoing monitoring functions for an audit client as incompatible with independence. Approving who keeps access to a financially significant application is a management decision. The auditor can test whether your reviews were performed, reviewed and acted on, but it should not perform them. Confirm the boundary with your auditor, and document who in management signs each review.
Can management rely on the auditor's ITGC testing for its own assessment?
No. PCAOB AS 2201 requires management to represent in writing that it did not use the auditor's procedures as part of the basis for its own ICFR assessment. Management must perform and document its own testing of the IT general controls that support its key financial reporting controls. The auditor then tests management's work independently. Build your evaluation plan so that every conclusion rests on your own evidence, and keep a record of who performed each test.
What happens if our auditor already did ITGC work for us?
It depends on what the work was and who did it. Rule 2-01 bars outsourced internal audit services relating to internal accounting controls, financial systems or financial statements, unless the results will not be subject to audit procedures. If the audit firm performed such work, it may not be able to test the same area without impairing independence, and management may need a different firm to evaluate it. For a SOC 1 report, SEC staff say management may rely on a Type 2 service auditor's report even when the same firm audits the company, but not when the registrant's own audit firm prepared that report. Ask the audit firm to review prior engagements against these rules before planning the year's testing.
Can an outside firm test our ITGCs instead of the auditor?
Yes, a firm independent of the audit firm can perform management's testing, and that is a common arrangement. Management still owns the evaluation and the conclusion, and it must be able to show that the outside tester is competent and objective. The external auditor may use that work as part of its own testing, but it must still perform its own procedures. Choose a firm that is not the company's audit firm, and confirm in writing how the auditor will treat its work before testing begins.
What does our team need to provide if outside help is involved?
Your team must keep control of the evaluation and the evidence. In practice that means:
- Named control owners for each in-scope application, database, infrastructure component and report
- A management owner who approves the scope, reviews test results and signs the conclusion
- Access to system configurations, logs, change tickets and population reports in a form the auditor can test
- A record of which firm performed each procedure and how management reviewed it
An outside partner can prepare systems and evidence, but only the company's management and its independent auditor can make the final determinations. Confirm the division of tasks in writing with your auditor and audit committee before work starts.
How to bring in an implementation partner while keeping your auditor independent
The core rule is simple: the implementation partner prepares systems, controls documentation and evidence, and the company owns the result, while the external auditor performs attestation work and must never be the party that designs, operates or monitors the controls it later tests. An independent partner can carry much of the preparation load, but only if the boundary between the two roles is written down before work starts. Start with a written scope that names each deliverable, the ITGC areas it covers (access, program changes, program development and computer operations), the systems in scope, and who on the company side approves each output. DeployOpen works from written, fixed-scope agreements of this kind, but the same discipline applies to any partner. Ask the auditor to review the draft scope before signing so that any concern about independence surfaces early, not during fieldwork.
Separate the people as well as the paperwork. The partner's engineers should configure, document and collect evidence, while a named employee who owns each control reviews and accepts that work and signs off on the control description. Management, not the partner, must make the decisions that the control requires, such as approving a privileged access grant or a production change. Keep a log that records who performed each preparation task, who reviewed it, and who approved it, because the auditor will ask how management formed its own conclusion. Documentation the auditor can inspect should show the original system output, the query or procedure used to produce it, the date it was generated and the approver. Confirm with the auditor, in writing, which artifacts it will accept as evidence and which it expects management to produce itself, since acceptance criteria differ between firms and engagements.
Plan for the representations that close the loop. Under PCAOB AS 2201, management provides written representations, including that it did not use the auditor's procedures as part of the basis for its own ICFR assessment and that it disclosed all deficiencies it identified. A partner's preparation work does not violate that representation, but internal testing performed by the auditor, or auditor-prepared test results reused as management's own, would. Before fieldwork, have management confirm which testing it performed itself, which it obtained from the partner, and which it took from another source. If the partner's findings reveal a deficiency, record it and route it through management's own evaluation rather than letting it disappear into a remediation ticket. Confirm these points with your own counsel or the audit firm, because the boundary depends on your facts, and treat any answer that is not in writing as unconfirmed.
