What to outsource for SOX ITGCs and what to keep in-house
If a Section 404 deadline, an auditor request or a board mandate has landed on your desk, start with the split of responsibility: management keeps ownership of its IT general controls and its own assessment of them, while an outside implementation partner can prepare systems, configurations and evidence on management's direction. The partner does not own the conclusion, and the external auditor does not issue it on management's behalf. Where that line falls depends on your filer status, the scope of financially significant systems and how much capacity your control owners and internal audit team have. No SEC rule or PCAOB standard publishes an ITGC catalog, so the split is something you define in writing for your own environment rather than something you copy from a template. SEC staff FAQ (Question 8) is explicit that management still has to assess controls over outsourced operations, even when it relies on a service auditor's report. In practice, this means keeping in-house the decisions that define the control: which systems are in scope, what the control objective is, who approves access and changes, what counts as an exception and how it is remediated. A partner can draft the procedures, configure the tooling, pull the populations and assemble the evidence binder, but a named manager must review the results, sign off on the assessment and be able to explain it to the auditor. Confirm with your external auditor which documents they expect management to own directly.
Independence limits what the partner and the audit firm may each do. Under SEC Rule 2-01(c)(4)(vi), your external auditor cannot act as a director, officer or employee of the audit client or perform decision-making, supervisory or ongoing monitoring functions for it. A partner that designs or operates your controls can usually still help with evidence and testing preparation, but the auditor must not take over those roles, and the two engagements should be documented separately. Before work starts, ask the partner to list which tasks it will perform, which remain with your staff and which you will review. Ask the auditor to confirm in writing which of that list it can rely on. For a deeper look at the auditor's side of this line, see the related sections on what the external auditor may do and on co-sourced internal audit.
Which SOX ITGC work partners commonly take on
Implementation partners usually take on the preparation work around SOX ITGCs: documents, populations, configured evidence and pre-audit test runs. Each item below stays under management's review and sign-off, and the partner never operates a control in place of the control owner.
Documenting ITGC narratives and walkthroughs
A partner can draft the narrative for each in-scope ITGC, describing who performs the control, which system it touches, how it is triggered and what record it leaves. Management must confirm each narrative matches how the control really runs, because a walkthrough that describes an idealized process will not survive auditor inquiry. Check that the narrative names a specific owner and a review step, not only a policy statement.
Mapping controls to in-scope systems
Partners often build the matrix that ties each ITGC to the applications, databases, operating systems and infrastructure it protects. Scope decisions belong to management, since they follow from which financial reports and processes the company has identified. Ask for the matrix to show the reasoning behind each inclusion and exclusion, so the auditor can trace scope back to risk.
Configuring access and change evidence
A partner may set up ticket fields, approval workflows and access-review exports so that approvals and reviews leave a usable record. The configuration is a preparation step; the owner still approves each access grant, reviews each privileged account and signs each change. Confirm that any reports generated from these configurations are tested for completeness and accuracy before management relies on them.
Collecting and organizing test populations
Partners frequently assemble the populations auditors sample from, such as lists of new users, terminated employees, production changes and backup jobs, along with screenshots and logs. Assembling a population is clerical work, but the completeness of the population is a control in its own right. Management should confirm the population came from the source system and reconcile it to an independent count before it goes to the auditor.
Running pre-audit test cycles
Some partners run a dry-run test of selected controls before the external auditor arrives, which can surface gaps while there is still time to fix them. These tests are a readiness check, not the independent testing the auditor performs or that management's own evaluation requires. Management should decide which controls are tested, review the results and own any conclusion about deficiencies.
Supporting remediation of failed controls
When an ITGC fails, a partner can help design the fix, document the corrected process and gather evidence that the fix operated for a sufficient period. The company decides whether the failure is a deficiency, a significant deficiency or a material weakness, and whether a compensating control is acceptable. Ask the partner to show which remediation steps are their work product and which require the owner's approval.
How responsibilities split between owners, management, partner and auditor
Control owners are the people who operate an IT general control day to day: the identity team that grants access, the platform team that moves changes into production, and the operations team that runs backups and handles incidents. They generate most of the evidence, such as approval tickets, access review sign-offs and restore logs. Their own self-assessments carry less weight because they are the people performing the control, so SEC guidance expects more objective testing where ICFR risk is high.
- Operate the control: Approve access, review changes and run backups as the control design says, and keep the records that prove it happened.
- Keep evidence complete: Retain approvals, exports and timestamps in a form that can be re-performed or inspected.
- Report exceptions: Raise failed reviews or unauthorized changes to management rather than closing them quietly.
- Support walkthroughs: Explain the control to testers and show how the system produces its reports.
Before year end, confirm with your control owners which tasks they perform themselves and which were moved to a partner or a managed provider, and document any handoff in writing.
Management owns the ICFR assessment. Section 404(a) requires management's annual assessment of internal control over financial reporting as of fiscal year end, and SEC staff FAQ guidance says management keeps responsibility for controls over outsourced operations even when it relies on a service auditor's report. The audit committee oversees this work. Neither can hand the judgment to a consultant or to the external auditor.
- Scope and risk decisions: Decide which applications, databases and infrastructure are in scope and document the reasoning.
- Evaluate deficiencies: Judge the severity of ITGC failures and their effect on IT-dependent controls.
- Oversee providers: Obtain and review provider reports, such as SOC 1 reports, and assess the controls they cover.
- Certify and disclose: Support the certifications and the management report filed with the SEC.
Confirm that a named executive owns the ITGC program and that the audit committee receives deficiency reports, since no partner or auditor can carry that accountability for the company.
An implementation partner such as DeployOpen prepares systems, controls and evidence for the company. Under an agreed written scope, the partner might configure identity and access tooling, build change-tracking workflows, set up backup monitoring, or assemble populations and evidence packages for management's testing. The partner does not issue audit reports or attestations, and it does not make the company's control decisions. The company retains the controls and the assessment.
- Build and configure: Set up the systems that run or record the controls, within the scope written in advance.
- Prepare evidence: Produce access reviews, change logs and restore reports that management and testers can inspect.
- Document design: Write control descriptions and procedures that the control owners approve.
- Support remediation: Help fix a failed control, with management deciding how the fix is validated.
Because a partner that performs ongoing monitoring or operates a control for the company can affect the auditor's independence, ask the external auditor in advance which tasks it will accept from your partner.
The external auditor tests ICFR under PCAOB AS 2201 and assesses IT risks under AS 2110. Under Rule 2-01(c)(4)(vi) of Regulation S-X, an accountant is not independent if it acts as a director, officer or employee of an audit client or performs any decision-making, supervisory or ongoing monitoring function for it. So the audit firm may test controls and rely on others' work, but it cannot run the controls or make management's decisions.
- Test independently: Perform its own testing of key ITGCs and decide how much to rely on internal audit or other personnel.
- Use others' work: Under AS 2201 paragraph 17, the auditor may use work from internal auditors, company personnel and third parties working under management's or the audit committee's direction.
- Assess competence and objectivity: Judge whether those providing work are qualified and independent of the controls they test.
- Avoid management functions: Do not design, operate or monitor the company's controls on an ongoing basis.
Before engaging any partner or co-sourced firm, ask the auditor in writing whether the planned work will affect its independence and whether it can rely on that work.
Why the external auditor cannot also build your controls
The external auditor cannot design, build or run the controls it will later test. SEC Rule 2-01(c)(4)(vi) of Regulation S-X says an accountant is not independent if it acts as a director, officer or employee of an audit client, or performs any decision-making, supervisory or ongoing monitoring function for it. For SOX ITGCs, that means the audit firm may not choose the access model, approve changes, own the backup schedule or act as the control owner for a system it audits. Confirm the exact boundary with your audit firm and its independence team before work starts, because the answer depends on the services already on the engagement.
An implementation partner that is not your auditor sits outside that prohibition, so it can configure systems, draft procedures, prepare access reviews and assemble evidence. The partner cannot take on management's decisions, though. Management still approves the control design, accepts or rejects risk, signs off on remediation and owns the ICFR assessment. Under SEC guidance, management also keeps responsibility for controls over outsourced operations, even when it relies on a service auditor's report. Write down which decisions management made and which work the partner performed, so the external auditor can see who did what.
Keep a work log that names the person, the date and the role for every ITGC task. Record who designed each control, who approved it, who performed each review and who prepared each evidence package. PCAOB AS 2201 lets the auditor use work performed by internal auditors, other company personnel and third parties under management's direction, but only if the auditor can see that arrangement. A clear record protects the independence of the audit firm, shows management's ownership and makes it easier to answer the auditor's questions about objectivity and competence.
Which ITGC tasks fit in-house and which fit an outside partner
This table compares four ways to divide SOX ITGC work: in-house execution, outside implementation support, co-sourced internal audit testing and full outsourcing of testing. Read each row against your system count, team capacity and first-year readiness, and note the column on what each option does not solve, because management keeps responsibility for the ICFR assessment under every option.
| Option | When it fits | What it does not solve |
|---|---|---|
| In-house execution | Small number of in-scope systems, a team that already runs access reviews and change approvals, and a stable control environment with prior-year testing history | Objectivity: people who operate a control assess it with lower objectivity, so the evidence may need direct testing by more independent staff |
| Outside implementation support | First-year readiness, a new ERP or cloud platform, or a gap in control design that internal staff have not built before | Ownership: the partner prepares systems, procedures and evidence, but the company still operates each control and owns the assessment |
| Co-sourced internal audit testing | Mid-sized environments where internal audit needs extra capacity or specialist IT audit skills for testing the ITGCs | Management's assessment: testers do not replace management's evaluation, and the firm must not make management decisions or operate controls |
| Full outsourcing of testing | Teams without internal audit capacity, or organizations that need an external tester throughout the year with documented independence | Accountability: it does not transfer responsibility for the ICFR conclusion, and the company must still oversee results and fix deficiencies |
| Work the external auditor may not perform | Any stage where the audit firm would design, operate or monitor the controls it will later test | Independence: the audit firm cannot act as a management function or perform ongoing monitoring for the same client |
How to set up the split before the audit year starts
This sequence turns a general idea of outsourcing into a written split of SOX ITGC work, so that each control has a named owner, each partner task has an agreed deliverable, and the evidence reaches internal audit and the external auditor in a form they can test. Management finishes the setup before the audit year begins so that the first control operations are already on the agreed split.
Scope the in-scope systems and controls
Management, with input from finance and IT, identifies the applications, databases, infrastructure, locations and reports that feed financial reporting, then maps the ITGCs needed for those systems to the four areas SEC guidance names: access, program changes, program development and computer operations. Management needs to evaluate only the ITGCs that support the reliable operation of other controls addressing financial reporting risk. The output is a scoping memo with a control inventory that lists each ITGC, the system it covers and the risk it addresses. Confirm that the scope matches the risk assessment the external auditor has reviewed before moving on.
Assign a named owner to each control
For every control in the inventory, management names one accountable owner inside the company, usually a system owner, IT manager or control owner in finance. The owner is responsible for the control operating and for the evidence it produces, even when someone else performs the work. Owners should sit outside the team that performs the control wherever practical, because self-assessments by people who operate a control generally provide less objective evidence. The output is an ownership matrix signed off by the control owner and the person who will review it.
Decide which tasks the partner prepares
Management and the partner separate work into tasks management keeps (approving access, approving changes, reviewing results, deciding on remediation and signing off on conclusions) and tasks the partner may prepare (gathering populations, drafting documentation, running extracts, setting up tooling and assembling binders). Management must still assess controls over any outsourced operation, including those a service provider performs, so the partner's role is preparation and support, not ownership of the conclusion. The output is a task split that lists each activity, who performs it and who approves it.
Agree the partner tasks in writing
Management and the implementation partner put the agreed split into a written scope with defined deliverables, format requirements for evidence, and a list of the systems and records the partner may access. The agreement should state that the partner does not approve access, changes or conclusions, and that it does not issue any audit report or attestation. Ask the partner to confirm in writing that it is not the company's external auditor and that its work will be independent of the audit firm. The output is a signed statement of work that both parties can point to when a question about roles arises.
Set review and sign-off points
Management defines when each piece of work is reviewed and by whom, including monthly or quarterly access reviews, change approvals before production, and a sign-off on the evidence package before it goes to auditors. Each review point has a reviewer who is not the person who prepared the evidence. The output is a calendar of review checkpoints with reviewer names, the evidence each checkpoint produces and the escalation path for exceptions. Confirm that every exception found in review has a documented disposition.
Hand evidence to internal audit and the auditor
Management sends the evidence package to internal audit and the external auditor using the format and channel both have agreed. Internal audit may use the work to test controls, and the external auditor may use the work of internal auditors, company personnel and third parties working under management's direction, subject to its own competence and objectivity tests. The output is a transmittal record showing what was provided, when, to whom and in which version, along with a list of open questions. Ask the auditor early which evidence it will sample and whether the partner's preparation work must be disclosed or reperformed.
Where outsourced SOX ITGC work goes wrong
Most problems with outsourced SOX ITGC work do not come from weak technical skill. They come from unclear ownership: who operates a control, who reviews it, and who decided what is in scope. Each card below names one common failure and the step that prevents it.
Partner operating controls for management
When a partner runs access reviews, approves changes or monitors alerts on management's behalf, the partner has taken a management function. Management still owns the assessment of its own ICFR, and an auditor cannot treat the partner's work as management's control if management does not perform it. Write down which person at the company performs each recurring control, and confirm the partner prepares the evidence rather than performing the decision.
Undocumented reviewer sign-off
A review that happened but was not recorded with a reviewer name, date and the population reviewed will not hold up in testing. Auditors need to see who reviewed what and what they looked for. Require every review to leave a dated record with the population and the exceptions found, and check that a named management reviewer signs it, not only the partner who prepared it.
Reliance on self-assessment by operators
When the people who run a control also assess whether it works, the evidence carries less weight. SEC guidance says self-assessments by operators generally provide less objective evidence, and high-risk controls need direct testing or monitoring by more objective personnel. Assign independent testing to someone who did not operate the control, whether internal audit, a co-sourced team or a separate partner engagement.
Scope drift without written change
Systems get added, retired or moved to cloud during the year, and the ITGC scope quietly changes with them. If the change is not documented, the auditor may test an outdated list and find systems that were never covered. Keep a dated scope register, require written sign-off for each addition or removal, and reconcile it against the system inventory before each testing cycle.
Treating the auditor as the designer
If the external auditor helps design the controls, its later independence is at risk, because SEC rules bar an audit firm from performing management functions or ongoing monitoring for an audit client. Management should design the controls, with a partner documenting and implementing them, and then give the auditor the design for its own testing. Keep a record showing management made the design decisions.
Forgetting oversight of provider controls
Outsourcing a system or a control does not outsource management's responsibility for it. SEC staff guidance says management must still assess controls over outsourced operations, even when it relies on a service auditor's report. Obtain each provider's report, map its controls to your own ITGCs, and document the gaps you cover internally.
Questions buyers ask about outsourcing SOX ITGCs
Can we outsource our whole SOX ITGC program to a partner?
No, not the accountability. A partner can prepare systems, run configuration work, collect evidence and support testing, but management must still assess its own internal control over financial reporting. SEC guidance says management keeps responsibility for controls over outsourced operations even when it relies on a service auditor's report, so a partner's work does not transfer ownership of any control. In practice, the split usually looks like this:
- Management owns the control design, the risk assessment, the decision to rely on a control, and the conclusion on effectiveness.
- Control owners perform and review the recurring activities, such as access approvals and change sign-offs.
- The partner prepares systems, documentation, evidence packages and remediation work within a written scope.
- The external auditor and, where used, the internal audit function test independently.
Can our external auditor help us build or run ITGCs?
Generally not. SEC independence rules bar an accountant from acting as a director, officer or employee of an audit client or from performing decision-making, supervisory or ongoing monitoring functions for it. Designing or operating the controls the auditor will test typically crosses that line, so the auditor cannot be the party that builds the control or runs the access reviews. Your firm can still provide a read-only view of what it expects to test, and the audit committee should confirm which non-audit services are permitted before work starts. Check the detailed rules in Regulation S-X Rule 2-01 with your counsel and audit committee rather than relying on a summary.
Does outsourcing reduce our auditor fee?
It can change the fee, but only if the auditor is able to use the work. Under PCAOB AS 2201, the auditor may use work performed by internal auditors, other company personnel and third parties working under management's or the audit committee's direction, after assessing their competence and objectivity. Clean, well-documented work with independent testers usually reduces the hours the auditor must spend re-performing procedures. Outsourced work that the auditor cannot rely on adds cost instead. The 2009 SEC study found that internal labor could make up more than 50 percent of total Section 404 compliance cost for 404(b) companies, so the staff time your team spends on evidence gathering is often the larger lever. Ask your auditor in writing which parts of the partner's work it plans to rely on before you sign.
What must management keep in-house for ITGCs?
Management must keep the parts of ICFR that are judgments and accountability. That means deciding which systems and controls are in scope, approving the design of each control, owning the evaluation of deficiencies and their severity, and signing the annual assessment. SEC guidance says self-assessments by people who operate a control provide less evidence because of their lower objectivity, so a separate reviewer or internal function should test high-risk controls. Keep the person who approves an access grant separate from the person who performs it, and keep the record of who decided what. Your partner can draft the analysis, but the conclusion must come from your management team.
How do we show the partner's work to the auditor?
Treat the partner's output as management evidence and document how it was produced. For each deliverable, record who performed the work, when, under what instructions, which system generated the data, and who reviewed it. Auditors test the completeness and accuracy of system-generated reports, so keep the query or report parameters and show that the population is complete. Maintain a single index that links each control to its evidence and the reviewer's sign-off. Agree the testing approach and sample expectations with the auditor early, so the partner's evidence is gathered in the form the auditor will accept.
What should the statement of work include for SOX ITGC support?
A useful statement of work names the controls and systems in scope, the four ITGC areas it covers, and the specific deliverables such as walkthrough documentation, configuration evidence and remediation plans. It should state who owns each control, who approves each deliverable, and how the partner hands evidence to management. Include the timeline, the review cycle, the change process for scope, and how issues or deficiencies are reported to management the same day they are found. Ask for a clear exclusion list, so that no one assumes the partner will certify effectiveness or act as the auditor. DeployOpen scopes most engagements as fixed-scope work agreed in writing before work starts, and any quote follows from that written scope.
Can we run the ITGC program ourselves without a partner?
Yes, many companies do, and the question is whether your team has the capacity and independence to do it well. The work that recurs each quarter, such as access reviews and change monitoring, needs steady staff time, and the work that is one-time, such as scoping, design documentation and remediation, often needs specialist skills. Estimate the internal hours for each control, identify who would test rather than perform each control, and check whether the same people cover multiple roles. If the gaps are in skills or in reviewer capacity, a partner can fill them under a written scope. Confirm your own staffing position with your audit committee and external auditor before deciding.
How DeployOpen works on this
DeployOpen works on the split between management, an implementation partner and the external auditor by preparing the systems, configurations and evidence that control owners and management review and sign off. We do not perform management's assessment, operate controls for the company, or issue audit reports or attestations, which remain with management and the independent auditor.
How we scope
- Agree in writing which controls, systems and evidence sets the partner prepares and which remain with named management owners.
- Record the boundary between partner work and management's own assessment, including who reviews each evidence set.
- Confirm with your external auditor which work it expects to rely on, before any preparation starts.
How we build
- Configure self-hosted open-source platforms in your own infrastructure so access, change and monitoring records are generated and retained.
- Document control design, owners and review cadence so management can evaluate each control with independent evidence.
- Test evidence extracts for completeness and accuracy so system reports can be relied on as populations.
How we hand over
- Deliver the control documentation, evidence packages and runbooks to the named management owners and internal audit.
- Walk management and internal audit through each evidence set so they can challenge and test it themselves.
- Provide a written record of what was built, changed and tested, so the company keeps ownership after the engagement ends.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, separate from the fixed-scope engagement.
- Maintain platform configurations and evidence routines as the systems change during the fiscal year.
- Ask management to confirm in writing who owns each control and who signs off on ICFR conclusions.

