What SOX ITGC documentation must contain before an auditor arrives
Management must keep evidential matter that reasonably supports its ICFR assessment, and under Instruction 2 to Item 308 of Regulation S-K that duty applies to every annual assessment, not only the first. The form is flexible. SEC guidance in Release 33-8810 accepts policy manuals, process models, flowcharts, job descriptions and memoranda, so a first-year team can meet the duty with a combination of ITGC narratives, a control matrix and a set of retained artifacts. The documentation only has to cover the controls management concludes address financial reporting risks, not every IT procedure in the company.
The right depth depends on each company's systems, risk and control design. A single ERP with automated approval workflows and privileged access tied to finance roles needs more detail than a small company whose key reports come from one application with few users. No SEC or PCAOB catalog fixes the list of ITGCs, so the scope should be set from your own in-scope applications, databases and infrastructure. Ask your external auditor early which control descriptions and evidence types they expect for each area, and record their answer, because it saves a rework cycle when fieldwork starts.
Roles should be settled before documentation is written. The organization owns its controls, its narratives and the evidence it relies on, and management signs the assessment. An implementation partner such as DeployOpen can prepare systems, configurations and evidence so the controls can be described and tested, but the partner does not decide which controls are key or conclude on them. Only the independent external auditor issues the attestation under Section 404(b), where it applies. Confirm in writing who prepares each narrative, who reviews it, and who keeps the signed versions, so that no gap appears between the team that built a control and the team that describes it.
What a control narrative for an ITGC should cover
A control narrative tells an auditor what a control is meant to do, how it works, and what proof it leaves behind. Each component below answers a question the auditor must settle before reperforming the test, so gaps in one card usually show up as problems in testing.
Objective and financial reporting risk
State the control objective in terms of the financial reporting risk it addresses, such as unauthorized changes to a ledger configuration or a batch job that drops transactions. Name the assertion it supports, for example completeness or accuracy of a financially significant report. Without this link, an auditor cannot decide whether the control is worth testing or how much evidence the risk requires. Check that the objective describes what could go wrong, not just what the team does.
Systems and data in scope
List the applications, databases, operating systems, interfaces and reports the control covers, with version and environment where relevant. Identify the data sources feeding any automated or report-based element. Auditors use this list to decide which populations to sample and whether a system change falls within the control. A narrative that names only the application and omits the database or interface often leads to testing the wrong population.
Control owner and reviewer
Name the role that performs the control and the independent role that reviews it, with the reviewer's authority to approve or reject. Describe how ownership transfers when people leave or roles change. Auditors check that the person who performs the control is not also the only person who reviews it, because that weakens the evidence. Confirm that each named role maps to an actual person in the access review and that the reviewer had enough context to judge the item.
Frequency and trigger
Define how often the control runs and what starts it, whether a calendar schedule, a transaction threshold, a change request or an alert. For manual controls, state the cutoff and the window in which review must complete. Auditors use the frequency to set the sample size and the period covered, so an ambiguous phrase such as "periodically" forces them to choose the most demanding assumption. Write the frequency in a way that a tester can count occurrences from the evidence.
Evidence produced and where it lives
Describe each artifact the control generates, such as a signed access review, a ticket with approval fields, a job log or a system report with its parameters. Record the system or folder where it is stored, the retention period and who can alter it. Auditors need to reperform the test from this evidence, so a report without its query parameters or a screenshot without a timestamp often cannot be relied on. Confirm that the report is complete and accurate before anyone relies on it.
Exception and escalation path
Explain what happens when the control detects a failure or a reviewer rejects an item: who is notified, how fast, how the exception is logged, and how it is resolved or escalated. Include the criteria for treating an exception as a deficiency that might need evaluation. Auditors test exceptions to see whether the control works in practice, not only on clean samples. A narrative that says nothing about exceptions leaves the tester unable to judge what happens when the control fails.
How to build a control matrix that links risks, controls and evidence
This sequence turns the scoped systems into a control matrix where every access, change, development and operations control traces to a financial reporting risk, an accountable owner, a named evidence artifact and a defined test attribute. The result is a set of rows an external auditor can follow without asking the control owner to explain each one.
Confirm the in-scope systems and reports
Start from the scoping decision and list each financially significant application, database, operating system, network component and the reports or interfaces that feed the financial statements. Management owns this list, and the IT, finance and internal control teams should sign off on it together. The check that closes the step is a scope register where every system names the business process it supports and the account balances or disclosures it affects, so each later row has a system to attach to.
Map each control to the risk it mitigates
For each system, record the IT general control areas that apply, such as access to programs and data, program changes, program development and computer operations, and state the financial reporting risk each control addresses. Include the IT-dependent application controls that rely on it, because an ITGC matters mostly for what it protects. The output is a matrix column that links every control ID to one risk statement, and any control that addresses only operational efficiency is left out of the ICFR matrix.
Write the control description and assign an owner
Write each control as a short narrative that says what is performed, how often, by whom, using which system, and what happens when an exception is found. Name one accountable owner by role and a backup, and confirm that the owner has the authority and knowledge to perform the control. Check the narrative with the owner in a walkthrough or review meeting, and record the date of that review in the matrix so the description can be shown to be current.
Define the evidence artifact for each control
For each control, name the specific artifact that proves it operated, such as an approval ticket, a system-generated access listing, a signed change record, a job log or a restore test report. Describe what the artifact must show, including the date, the approver, the population and any system-generated report parameters. Where a report comes from a system, record how it was produced so an auditor can ask for the same output. The check is that every control has at least one artifact that could be reproduced by someone who was not involved in the original work.
Set the retention location and access rules
Identify where each artifact is stored, such as a ticketing system, a log repository or a controlled document folder, and who can read, change or delete it. Confirm the retention period with the company's records policy and any regulatory obligations that apply to the entity, because the matrix should not guess these. Restrict write access to evidence stores so that the reviewer can trust that what they see is the record as it was created. The output is a column in the matrix that gives a location and access owner for each artifact.
Record the test attribute for each control
For each control, define the attributes an auditor would check, such as whether approval occurred before the change was deployed, whether the reviewer was independent of the requester, or whether the access listing covered all users. Record the population, the frequency and the expected evidence for a sample, so testing can be repeated on the same terms. Note which controls are automated and which depend on manual review, because that affects how the test is designed. The output is a test attribute table that a second tester could follow to reach the same result.
Trace each row from risk to evidence
Run a traceability check across the matrix, starting from a risk statement and moving through the control, owner, artifact, storage location and test attribute, and then reversing the path from a sample artifact back to the risk. Look for gaps such as controls without artifacts, artifacts that do not match any attribute, or risks with no mitigating control. The sequence is complete when a person outside the project can select any row and find the evidence without help, and the gaps are logged for remediation or documented as accepted scope decisions.
How evidence should match the risk of each ITGC
Access controls decide who can change financial applications, databases and infrastructure. An assessor who wants to test this area needs records that show who held access, who approved it, and whether the access was still appropriate on the dates tested. Testing typically combines inquiry of the access administrators, observation of how requests are submitted, inspection of approval and review records, and reperformance, such as comparing a system user list against the HR roster for leavers and transfers.
- Access request and approval records: Tickets showing the requester, the business approver, the role granted and the date, so the assessor can trace each sampled grant back to authorization.
- Periodic user access review results: Signed or system-recorded reviews listing each user and role, with the reviewer's decision and the follow-up on any removals.
- Termination and transfer logs: Dated records that match departures and role changes to the removal or modification of access.
- Privileged access evidence: Lists of administrator and superuser accounts, the approvals behind them, and logs of their use.
- System-generated user listings: Exports with the report parameters and run date recorded, so the population is complete and can be reperformed.
Confirm with your auditor which populations they will request and whether they accept system reports that you have not validated for completeness and accuracy.
Program change controls make sure modifications to financially significant applications, configurations and infrastructure are authorized, tested and approved before they reach production. Evidence here should let an assessor follow one change from request through testing and deployment. Reperformance is most practical when the ticket, the test record and the production deployment record share a common identifier that the assessor can trace in both directions.
- Change tickets with authorization: Requests showing the description, business justification and approval by someone with appropriate authority before development starts.
- Test results and sign-off: Records showing what was tested, by whom, the outcome and the approval to promote the change.
- Segregation evidence: Deployment logs or role assignments showing that the developer did not also move the change to production, or a documented compensating review where that is not possible.
- Emergency change records: Documentation of urgent changes, the after-the-fact approval and the review that followed.
- Production deployment logs: System records of what was deployed, when and by which account, which the assessor can compare with the approved tickets.
Check whether your change population is complete, meaning every production change appears in the ticketing system, because auditors often test from the production side to catch unrecorded changes.
Program development controls cover acquiring, building and implementing new financially significant systems, including testing, data conversion and go-live approval. This area is tested less often than access or changes, but when a new system or major release goes live during the year, the records must show that the system was tested and approved before it started producing financial results. Assessors typically inspect project documents and reperform key checks, such as confirming that converted balances agree to source reports.
- Project approval and scope documents: Records showing who authorized the project, the requirements the system must meet and the sign-off on design.
- Test plans and results: Documented test scripts, results and defect resolution, including user acceptance testing with the approver's signature.
- Data conversion reconciliations: Comparisons of source and target balances, with the differences investigated and resolved.
- Go-live approval: A dated decision by management to place the system into production, linked to completed testing.
- Post-implementation review: Evidence that the outcome was compared with the requirements, and that access and configuration were set up as approved.
Identify early which systems the auditor treats as in scope for this area, since a system that was not implemented during the period may need no program development evidence at all.
Computer operations controls keep financially significant processing running completely and accurately. These include job scheduling, backups and recovery, incident handling and oversight of IT service providers. Evidence should show that scheduled jobs ran as designed, that failures were detected and resolved, and that data could be recovered. Job logs and monitoring records are usually the strongest evidence here because they are generated automatically and can be reperformed against the schedule.
- Job scheduler logs: Exports showing each financially significant job, its schedule, its completion status and any reruns or failures.
- Failure and incident tickets: Records of processing errors, their investigation and the corrective action taken.
- Backup and restore evidence: Backup job logs plus records of test restores, showing that data can be recovered, with the date and scope of each test.
- Monitoring alerts and reviews: Alert configurations and records showing that someone reviewed alerts and acted on them.
- Service provider reports: Reports, such as SOC 1 reports where available, reviewed by management with exceptions and complementary user controls assessed.
Confirm the retention period for job and backup logs with your auditor before the year begins, because logs that roll off before testing cannot support the period under review.
Which evidence holds up and which tends to fail
This table compares common SOX ITGC evidence types by how easily an auditor can verify completeness, date, period covered and reviewer independence. Read each row to see where the evidence type fits on its own and where it needs supporting detail before an assessor will rely on it. The main takeaway is that evidence is judged by what it proves, not by how much of it exists.
| Evidence type | Verifiable completeness, date and period | Reviewer independence and when it fits |
|---|---|---|
| System-generated report with parameters | Strong when the report shows the run date, the query parameters, the population and the record count. Auditors can re-run it. | Fits most automated and user access controls. Independence depends on who ran it; a report pulled by the control owner needs a separate reviewer sign-off. |
| Screenshot of a system screen | Weak on its own. It rarely shows the population, the period or the time of capture, and it can be edited. | Fits as a supporting item for configuration settings. Add the report or query that produced the screen and the date of capture. |
| Email approval | Moderate. The sender, timestamp and content are visible, but completeness of the approval set is hard to show without a log. | Fits low-volume approvals if the approver has authority under the documented matrix. Pair with the change or access ticket it approves. |
| Signed form or ticket with approval fields | Strong when the workflow tool stamps dates, approvers and status changes. Paper forms need a complete, sequential register. | Fits access requests and change approvals. Confirm the approver is not the requester or the developer of the change. |
| Verbal confirmation or inquiry | Weak. Nothing is retained for re-performance, so it cannot show period coverage. | Acceptable only as one part of a test under the PCAOB inquiry-plus-corroboration approach. Always pair it with documents or re-performance. |
| Reconciliation or review log | Strong when it shows the population reconciled to the source, the reviewer, the date and the exceptions followed up. | Fits review controls over reports and interfaces. Confirm the reviewer has the knowledge and the access to challenge the figures. |
Common documentation gaps that delay the audit
Most delays in a SOX ITGC audit come from documentation that no longer matches the environment or cannot be re-performed. The gaps below share one root cause: the narrative, control matrix and evidence were written once and not kept in step with systems, people and retention practice.
Undocumented interfaces
Every feed that moves financially significant data between systems is a point where a control can silently fail. Auditors ask how a ledger balance was populated, and an undocumented interface or file transfer leaves that question unanswered. Inventory each interface in the narrative, name its owner, and record how completeness and accuracy of transferred data is checked, such as record counts or control totals. Confirm the inventory with the application owners rather than with the system documentation alone.
Stale narratives after system changes
A narrative describing a process that changed six months ago is worse than none, because it asserts a control that no longer operates as written. Tie narrative review to the change management process so that any release, configuration change or new approver triggers an update. Record the review date and reviewer on each narrative. Ask control owners to walk through the current process against the document before the auditor does.
Reports without completeness checks
Management often relies on system-generated reports, such as user access listings or exception reports, to perform a control. If the report omits records or filters them incorrectly, the review built on it proves nothing. For each report used in a control, document the source system, parameters, and how the population was confirmed as complete and accurate. Keep the query or report definition with the evidence so the report can be re-run and compared.
Evidence with no retention rule
Screenshots, approval emails and ticket exports are often scattered across personal drives and inboxes, and disappear when staff leave or systems are decommissioned. Set a retention rule for each evidence type that covers the full period the control operated, and store it in a location with access controls and a named custodian. Management is responsible for keeping evidential matter, so the retention rule should be written down and followed, not assumed from the platform's defaults.
Controls described but not owned
A control matrix entry without a named, accountable owner tends to be performed by whoever is available, and the auditor cannot confirm who reviewed what. Assign each control to a person with the authority and time to perform it, and name a backup. Record the owner's role, the frequency, and the evidence they produce. Confirm ownership in writing with each owner, because an owner who has never read the narrative cannot explain the control in a walkthrough.
Who writes, reviews and retains the documentation
Management owns the internal control over financial reporting and the annual assessment under Item 308 of Regulation S-K. That ownership includes keeping evidential matter that gives reasonable support for the assessment. In practice, control owners in IT and in the finance process areas write or approve the narratives, confirm that the control matrix reflects how systems actually run, and keep the records that show each control operated. Management also decides which controls are key, which evidence matches each risk, and what the retention period will be.
- Narratives and matrices: Control owners describe each ITGC, its objective, the system it covers, the people who perform it and the frequency.
- Evidence retention: Management sets where tickets, approvals, access reviews and job logs are stored and who can alter them.
- Sign-off: A named manager approves each control description and confirms it reflects current practice.
- Assessment decisions: Management concludes which deficiencies exist and whether any is a material weakness.
- Representations: Management gives the auditor written representations, including that it disclosed all deficiencies it identified.
Before the year starts, confirm with your auditor which documents they expect and in what form.
An implementation partner can prepare the technical side of SOX documentation. For self-hosted open-source platforms, DeployOpen's work in this area is to configure the systems so the right records are produced, draft control descriptions for management to review, and set up evidence collection in the client's own environment. The partner does not own the controls, decide whether a deficiency is material, or certify the results. Those remain with management and the auditor.
- Draft documentation: The partner can draft narratives, flowcharts and matrix entries from system configuration, which management then reviews and approves.
- Evidence pipelines: The partner can configure logging, change tickets and access exports so the evidence is reproducible.
- Retention setup: The partner can set up storage, retention and access controls for evidence within the client's infrastructure.
- Walkthrough support: The partner can help control owners prepare for walkthroughs by mapping transactions through systems.
- Scope boundary: Written scope should state which documents the partner drafts, which management approves, and which the partner never signs.
Ask any partner to name each deliverable and the person at your company who accepts it.
The external auditor tests ICFR under PCAOB AS 2201 and issues the attestation report where Section 404(b) applies. The auditor reviews management's documentation to judge whether it is adequate, selects evidence to test, and forms its own conclusion. Auditors may use internal audit work when it meets competence and objectivity standards, but they cannot take over management's assessment. The auditor also cannot prepare the documentation it later tests without compromising independence.
- Review of documentation: The auditor checks that narratives and matrices describe the controls that address financial reporting risks.
- Testing: The auditor performs inquiry, observation, inspection and re-performance to test operating effectiveness.
- Independence: The auditor may not design or operate the controls it audits, and it does not sign management's assessment.
- Attestation: Only the independent auditor issues the attestation report.
- Communication: The auditor reports significant deficiencies and material weaknesses to management and the audit committee.
Confirm early which documents your auditor will request and whether they will accept internal or co-sourced testing.
Questions buyers ask about SOX ITGC documentation
How much documentation is enough for SOX ITGCs?
Enough to show that each control management relies on is described, owned, and backed by evidence that a reviewer can follow and retest. SEC guidance in Release 33-8810 accepts many forms, including policy manuals, process models, flowcharts, job descriptions and memoranda, and says documentation only needs to cover the controls management concludes adequately address financial reporting risks, not every step in a process. The volume that drives effort comes from scope: the number of financially significant applications, databases, infrastructure components and the control areas that touch them. Ask a partner to show how the control matrix maps each control to a risk and to its evidence, so you can judge coverage before any narratives are written.
Can a partner write the ITGC narratives for us?
A partner can draft narratives and prepare the supporting evidence, but management must own the controls and approve the final wording. Under Instruction 2 to Item 308 of Regulation S-K, the registrant must maintain the evidential matter that supports its assessment, so the company keeps that record. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue audit reports or attestations, and independent auditors issue those. Draft narratives should be checked by the control owners who run the process, because an external reviewer will ask them the same questions during a walkthrough. Confirm in the written scope who drafts, who reviews, and who signs off.
What do control owners need to provide for ITGC documentation?
Control owners need to explain how their control works in practice and point to records that show it ran. Typical inputs include access request and approval tickets, change records with testing and approval evidence, job schedules and backup logs, incident tickets, and vendor reports for outsourced services. Owners also need time to walk through a real transaction or change with the person preparing the narrative, since descriptions written from policy alone often miss the exceptions an auditor will probe. The effort rises when records are scattered across tools or when owners have changed during the year. Agree on a named owner for each control and a point of contact for evidence requests before the work starts.
How long does SOX ITGC documentation preparation take?
The duration depends on the number of in-scope systems, how mature the existing documentation is, and how quickly owners and reviewers respond. Organizations with current policies and ticketed evidence usually need less time than those documenting controls for the first time or reconciling several legacy platforms. Management should also allow time for review cycles, because narratives that change after a walkthrough must be updated and retested. No standard duration applies across companies, so ask a partner to state assumptions for scope, number of applications, and owner availability in the quote, and to set milestones against your external audit calendar.
Can management document SOX ITGCs without outside help?
Yes, management can prepare its own ITGC documentation, and SEC guidance does not require outside consultants. The work is still demanding, because the documentation must cover the controls that address financial reporting risks, show how evidence matches each risk, and support later testing. Internal teams often underestimate the time needed to gather historical evidence and to keep descriptions consistent across access, change, development and operations areas. A useful check is to have someone outside the control's operation review the narratives and matrix against sample transactions. Outside help can add capacity, but the company still owns the evidential matter.
What should we ask a partner to include in a quote?
Ask for a written scope that lists the systems, control areas, locations and deliverables, so each cost driver is visible. A useful quote states who prepares narratives, who reviews them, how evidence is collected and stored, how many review cycles are included, and what the partner will not do, such as issuing an audit opinion or deciding which controls are in scope. Ask how changes to scope are priced and whether ongoing support is separate from the initial documentation. DeployOpen does not publish a price list, and a quote follows from the written scope, so compare proposals on the same deliverables rather than on headline totals.
How DeployOpen prepares ITGC documentation and evidence
DeployOpen helps organizations prepare the IT general control documentation and evidence that management keeps for its ICFR assessment. We plan and document the controls in your own environment, while your team owns the controls and an independent auditor issues any report or opinion.
How we scope
- Written scope agreed before work starts, listing the systems, controls and control areas covered
- Confirmation of which applications, databases and infrastructure your team has identified as financially significant
- Agreed list of control descriptions, owners and evidence sources to be documented in the engagement
How we build
- Control narratives drafted from walkthroughs with your control owners and reviewed by them
- Control matrices linking each control to its objective, owner, frequency, system and evidence source
- Evidence collection set up in your own systems so samples can be pulled and re-performed by reviewers
How we hand over
- Documentation delivered in formats your team and auditors can maintain after the engagement ends
- Evidence index mapping each control to the artifacts, date ranges and locations an auditor would request
- Handover session walking your staff through how to refresh narratives and evidence at each assessment cycle
How we support
- Fixed-scope delivery with deliverables and timelines confirmed in writing before work starts
- Ongoing support, upgrades and continuous testing available as a retainer for later assessment cycles
- Questions about what your auditor will accept should go to the auditor early, before documentation is finalized
