How management testing of SOX ITGCs works and what evidence it needs
Management supports its annual 404(a) conclusion on IT general controls by gathering its own evidence, through direct testing, ongoing monitoring or both. Under SEC guidance in Release 33-8810, the sufficiency of that evidence depends on its quantity, such as sample size, and on its qualities, including the procedures used, the period covered and the objectivity of the people who performed the work. For the finance or IT leader signing off on the conclusion, the practical question is whether the evidence behind each in-scope ITGC is large enough, recent enough and produced by someone independent enough to support the assessment.
The right mix depends on three factors. The first is ICFR risk: when risk is high, evidence would ordinarily come from direct testing or monitoring by more objective personnel, while low-risk controls may rely on ongoing monitoring alone, with evidence drawn from a reasonable period that includes fiscal year end. The second is centralization. Daily interaction with controls can give sufficient evidence in a small company where controls are centralized and few people are involved, but generally not where there are multiple reporting layers or operating segments. The third is who performs the work. Self-assessments by the people who operate a control provide less evidence because of their lower objectivity, so a control owner checking their own access reviews should not be the only evidence behind a high-risk conclusion.
Management owns the controls and the conclusion. An implementation partner can prepare systems, extract reports and organize evidence for each test, but it cannot make the assessment or stand in for management's evaluators. Where the company is subject to the auditor attestation, only the external auditor issues that attestation. Before contracting for help, confirm in writing which tests the partner will prepare, who will perform and document them, and which evidence will be retained for management and for the auditor to reperform. Any deficiency that testing reveals must then be evaluated to determine whether it is a material weakness.
Direct testing, monitoring and self-assessment compared
Direct testing is a specific test performed to determine whether a control operated as designed during the period. SEC guidance treats it as one of two ways management can obtain evidence of operating effectiveness, the other being ongoing monitoring. The evaluator selects items, inspects the supporting records and compares the results to the control's expected operation. Evaluators are usually internal audit, a compliance team or a qualified person independent of the control owner.
- Who performs it: Someone with a testing or compliance role who does not operate the control, such as internal audit or a central compliance function.
- Procedures: Inquiry combined with inspection of records, reperformance of the control, and sample selection with a documented rationale.
- Evidence yield: Depends on sample size, period covered and the objectivity of the evaluator, which SEC guidance names as the factors that set sufficiency.
- Where it fits: Usually the stronger source when ICFR risk is high, since SEC guidance says evidence would ordinarily come from direct testing or monitoring by more objective personnel.
- Cost driver: Sample sizes, the number of systems in scope and the time needed to gather populations for reperformance.
Confirm with your audit committee and external auditor which controls they expect to see direct testing for, and whether they accept the sample sizes and period you plan to cover.
Ongoing monitoring is management's recurring activity that tracks whether controls keep working. SEC guidance describes it as including self-assessment procedures and the analysis of performance measures designed to track control operation. It runs as part of normal business, so it can supply evidence across the year without a separate test event. Its weight depends on how independent the monitoring is and how well it is designed.
- Who performs it: Management or a monitoring function, which may include the control owner's supervisor performing reviews.
- Procedures: Review of exception reports, access reviews, reconciliations and performance metrics that show whether a control is functioning.
- Evidence yield: Continuous across the year, but only as strong as the metrics chosen and the review's independence from the people operating the control.
- Where it fits: SEC guidance says that when ICFR risk is low, management may conclude monitoring evidence is sufficient without direct testing, provided the evaluation considers a reasonable period including fiscal year end.
- Cost driver: The effort to define meaningful metrics, retain reports and show that reviewers followed up on exceptions.
Check that each monitoring report shows who reviewed it, when, and what follow-up was taken on exceptions, since auditors will ask for that trail.
A control self-assessment is a process in which the people who operate a control evaluate it themselves and report the results. It can be useful for raising awareness and catching problems early, but it produces the weakest form of evidence for the 404(a) assessment. SEC guidance says self-assessments by the people who operate a control generally provide less evidence because their objectivity is lower.
- Who performs it: The control operator or the owner's team, completing a questionnaire or checklist about the control.
- Procedures: Answering structured questions, attesting that a control ran, and sometimes attaching screenshots or reports.
- Evidence yield: Generally less, because the evaluator is not independent of the control, so it carries limited weight on its own.
- Where it fits: Useful as a supplement to direct testing or monitoring, and sufficient in some low-risk cases only when the self-assessor's objectivity is judged adequate.
- Cost driver: Low direct cost, but the reviewer's time to challenge answers and corroborate them with records can be significant.
Ask your auditor early whether a self-assessment will be accepted for any ITGC in scope, and what corroborating records they will expect alongside it.
How objectivity and ICFR risk change the weight of management evidence
Under SEC guidance, evaluator objectivity is a quality of evidence, weighed alongside quantity and the period covered. Release 33-8810 says the sufficiency of evidence of operating effectiveness depends on how many items were examined, the procedures used, the period covered and how objective the people doing the evaluation were. Management therefore cannot simply count its self-assessments and call the file complete. For each ITGC, the evaluation should record who performed the procedure, whether that person operates the control or reports to someone who does, and how that affects the conclusion. A change approval reviewed by the developer who submitted it, for example, carries less weight than the same review performed by someone independent of the change.
The weight of evidence also moves with ICFR risk. Where risk is high, the guidance says evidence would ordinarily come from direct testing or monitoring by more objective personnel, so self-assessment by the control operator is rarely enough on its own for a control over a significant account. Where risk is low, management may conclude that ongoing monitoring provides sufficient evidence without separate direct testing, provided the evaluation considers a reasonable period during the year, including fiscal year end. Confirm your risk rating for each ITGC with your external auditor early, because a rating that is too low will be challenged and a rating that is too high will add testing you did not need.
Testing or compliance authorities, such as internal auditors, are normally expected to be the most objective evaluators of controls. Other personnel, such as a controller's team or an IT compliance lead who does not operate the control, may be objective enough for lower-risk controls, but that judgment has to be documented and defended. Ask whether each evaluator has a reporting line independent of the control owner, whether they have the technical skill to reperform the test, and whether they can raise findings without management approval. If the answer is no for a high-risk control, plan for independent testing before the auditor asks.
When daily interaction with controls is enough in a small company
SEC guidance allows management's daily interaction with controls to serve as evidence, but only under specific conditions. The cards below set out each condition, what to confirm in your own environment, and the point where the approach stops holding up.
Controls are centralized
Daily interaction works best when the financially significant controls, systems and administrators sit in one place, so a single manager sees them operate. Confirm that access approvals, change approvals and job monitoring all run through the same small set of people and tools. If a second data center, a separate ERP instance or a business unit runs its own admin rights, the central view is no longer complete and direct testing or monitoring by a more objective person becomes necessary.
Few people involved
The approach depends on a small group of control owners whose activity the manager can observe and question directly. Confirm the actual headcount with privileged access to financial applications, databases and infrastructure, and check whether any one person both requests and approves changes. A small team with overlapping duties can still be acceptable, but the lack of segregation makes the manager's observation a weaker basis for conclusions.
No multiple reporting layers
Daily contact works when a control result travels directly from the person performing it to the person evaluating it, with no intermediate layers that filter or summarize what happened. Map each ITGC from the performer to the reviewer and count the handoffs. Where a control passes through a regional lead, a service desk and a steering group before anyone senior sees the output, the manager's interaction no longer reaches the underlying evidence.
No separate operating segments
A single operating segment means one set of processes, one rulebook and one set of systems for the manager to watch. Confirm that subsidiaries, acquired entities and separate product lines do not run their own change, access or job processes outside the central view. Each additional segment with its own procedures typically needs its own evidence, so the daily interaction covers only the segment the manager actually sees.
Interaction documented as evidence
Observation alone is hard to reperform, so management should record what it saw. Keep dated notes, meeting minutes or review sign-offs that state which control was observed, what was checked and what the result was. Confirm the records would let a reviewer who was not present understand the conclusion. Undocumented conversations rarely satisfy an auditor, even when the manager is well informed.
Low ICFR risk for the control
Under the guidance, daily interaction can stand in for direct testing only where the risk that a control fails to prevent or detect a material misstatement is low. Before relying on it, ask the team to rate each ITGC by financial reporting impact and by the likelihood of failure, and document the rating. When a control over financially significant data scores as high risk, plan direct testing or monitoring by a more objective evaluator instead, and make sure the approach still covers the fiscal year end.
How management plans, performs and documents its ITGC testing
The sequence moves from defining which IT general controls matter to a documented conclusion on whether each one operated effectively, so that the 404(a) assessment rests on evidence an outside reviewer can follow and repeat.
Scope the in-scope ITGCs
Management starts from the financially significant applications, databases, infrastructure and reports already identified in its ICFR scoping, then lists the IT general controls needed for those automated or IT-dependent controls to work consistently. SEC guidance limits this to ITGCs that support financial reporting risks, so controls that only affect operational efficiency are left out. The output is a scoped ITGC inventory that names each control, the system it covers and the financial reporting control it protects.
Assign evaluators by objectivity
Management assigns each control to an evaluator and records why that person is suitable. Control operators can run monitoring activities on their own work, but their self-assessments carry less weight. Where ICFR risk is high, the evaluator should be someone independent of the control, such as internal audit or a compliance function. The output is an evaluator assignment list with the objectivity rationale written beside each name.
Choose direct testing or monitoring per control
For each control, management decides whether its evidence will come from direct testing, from ongoing monitoring, or from both. The decision turns on ICFR risk. Low-risk controls may rely on monitoring evidence gathered over a reasonable period that includes fiscal year end, while higher-risk controls ordinarily need direct testing or monitoring by more objective personnel. The output is a test approach per control that states the reason for the choice.
Define procedures, population and sample
The evaluator writes the test procedure for each control, identifies the population of changes, access grants, job runs or tickets the control covers, and sets a sample size that matches the control's frequency and risk. Monitoring routines are written down as well, including the performance measures used to track the control. Sufficiency depends on the procedures used, the period covered and the objectivity of the evaluator, so each choice is recorded. The output is an approved test plan that another reviewer could reperform.
Perform tests and gather evidence
The evaluator executes the planned procedures, collects the underlying records and retains them with the request, approval and result attached. Monitoring evidence, such as periodic self-assessment results and exception reports, is gathered across the period set in the plan. Exceptions are logged when they occur rather than explained later. The output is a completed workpaper set for each control with evidence references and a stated result.
Evaluate exceptions and deficiencies
Management reviews each exception and decides whether the control operated effectively. If a control is not operating effectively, a deficiency exists and must be evaluated to determine whether it is a material weakness, considering the likelihood and magnitude of a misstatement in the financial statements and any compensating controls. Reviewers document the rationale even when the conclusion is that no deficiency exists. The output is a deficiency evaluation for each exception, with a severity conclusion and an owner for remediation.
Document the conclusion for 404(a)
Management consolidates the workpapers, the scoping decisions, the evaluator objectivity rationale and the deficiency evaluations into a single ICFR evaluation file that supports its conclusion on ITGC effectiveness. The file should show how evidence was matched to risk and how the period covered reaches fiscal year end. Management's conclusion feeds the 404(a) report, and the external auditor later reviews the same file when it plans its own work. The output is a signed-off ITGC evaluation memo and an indexed evidence file that can be provided on request.
What management must have in place before testing starts
Management cannot test ITGCs it has not first scoped, described and assigned. The four cards below cover the inventory, the control descriptions, the evidence and measures, and the people and calendar that together make direct testing, monitoring and self-assessment usable as evidence for the 404(a) assessment.
Documented ITGC inventory tied to risk
Start with a list of the applications, databases, infrastructure and interfaces that feed financial reporting, and the ITGC areas each one depends on for access, program changes, program development and computer operations. SEC guidance says management only needs the ITGCs necessary for other controls addressing financial reporting risks to operate properly, so each entry should name the financial reporting control it supports. Check that every in-scope system traces to a reporting risk, and that out-of-scope items have a stated reason.
Written control descriptions
Each ITGC needs a description that states the objective, the control activity, the owner, the frequency and the system it runs in. A description written loosely cannot be tested consistently, and two testers reading it may check different things. Ask the control owner to confirm the description matches how the control runs today, and compare it against a recent change record or ticket to confirm it is current.
Identified evidence sources and performance measures
Name where the evidence for each control will come from, such as access review exports, change tickets with approvals, backup job logs or incident records, and who can produce it. Where management relies on ongoing monitoring, define the performance measures that track whether the control works, such as the count of unreviewed access grants. Confirm each source is complete and unaltered before testing begins, because evidence that cannot be reproduced carries little weight.
Evaluators independent of the operators
Assign named evaluators who do not operate the controls they test. SEC guidance says self-assessments by people who run a control generally provide less evidence because of lower objectivity, and that internal auditors are normally expected to be the most objective evaluators. In a small company, a person outside the control's operation may still be enough when ICFR risk is low. Record who evaluates each control and why they are objective enough for that risk level.
Testing calendar covering year end
Set a calendar that places each test or monitoring activity within a reasonable period of the year, including the fiscal year end date. SEC guidance says the evaluation would ordinarily consider evidence from a reasonable period during the year, including fiscal year end, so a schedule that stops at mid-year leaves a gap the auditor will ask about. Confirm the owner of the calendar, the dates each evaluator reports, and how changes made after testing will be captured.
Questions about management testing of SOX ITGCs
Can management self-assess SOX IT general controls for the 404(a) assessment?
Yes, but the weight of the evidence depends on who performs the work. SEC guidance in Release 33-8810 says evidence of operating effectiveness can come from direct testing, ongoing monitoring or both, and that self-assessments by the people who operate a control generally provide less evidence because of their lower objectivity. Self-assessment can still contribute to the assessment, especially for lower-risk controls, but for high-risk ITGCs the evidence would ordinarily come from direct testing or monitoring by more objective personnel. Management owns the conclusion either way, so the evaluators must be able to show why their work is objective enough for the risk involved.
How much ITGC testing is enough for management's assessment?
There is no fixed number. SEC guidance says sufficiency depends on quantity, such as sample size, and on qualities including the procedures used, the period covered and the objectivity of the evaluators. Management's evaluation would ordinarily consider evidence from a reasonable period during the year, including fiscal year end, and when ICFR risk is low, ongoing monitoring alone may be sufficient. The practical question to ask is whether the evidence, taken together, supports a conclusion for each in-scope control at the assessment date. Your external auditor's expectations and the risk of each control will shape the answer, so confirm both before you set the testing plan.
Who should perform management's SOX ITGC testing?
Ideally, someone who does not operate the control and does not report to the people who do. SEC guidance 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, though other personnel may be objective enough depending on ICFR risk. In practice, companies use internal audit, a compliance function independent of the control owner, or a co-sourced team. Whoever performs the work should understand the control design, have enough technical knowledge to test the system, and document what they tested and why.
Can a small company rely on daily management interaction for ITGCs?
Sometimes. SEC guidance says management's daily interaction with controls may give sufficient evidence in smaller companies where controls are centralized and few people are involved, but generally not where there are multiple reporting layers or operating segments. A small team where the finance lead sees the system every day, approves changes and reviews access may have that visibility. Confirm the assumption with your auditor before relying on it, and document what the daily interaction actually shows, because informal awareness is hard to reperform and hard to defend when a control fails.
What does management testing need from internal IT and finance staff?
It needs people who can produce complete and reliable records. Typical requests include current access listings, change tickets with approvals and test results, job and backup logs, incident records, and the documented control descriptions that explain each control's purpose. The work also needs staff who can answer questions about how each control operates and who can rerun a report on request. Populations must be complete, which means the report used to select samples should be traced to source systems. Staff time is a recurring cost, so ask the people who run the controls to estimate their hours before testing starts.
How does management testing differ from external auditor testing?
Management's testing supports its own 404(a) conclusion, while the external auditor independently tests controls under PCAOB AS 2201 and assesses IT risks under AS 2110. Management's evaluation is ongoing and may use monitoring and self-assessment, but the auditor must form its own opinion and decides how far it can rely on management's or internal audit's work. Auditors also examine the objectivity and competence of the evaluators. Management should not expect the auditor to accept its work without review, so the evidence should be documented in a form the auditor can inspect and reperform.
What should I ask a consultant before hiring one for management testing?
Ask what the engagement covers, who performs the testing, and whether that person is independent of the controls being tested. Request a written scope that lists the controls, systems, testing procedures and deliverables, because fixed-scope work is easier to compare and to hold to account. Ask how the consultant will document evidence for reperformance, how it will coordinate with your external auditor, and which tasks remain with your staff. DeployOpen plans and implements open-source platforms, runs security testing, and prepares systems and evidence for compliance assessments, but it does not issue audit reports or attestations, and an independent auditor issues any opinion. Ask for a quote that follows from the written scope.
Who owns management testing and who can prepare the evidence
Management owns the conclusion on internal control over financial reporting, including the IT general controls that support it. Under the SEC's guidance in Release 33-8810, management must gather evidence that its controls operate effectively, decide how much weight each source deserves, and evaluate any deficiency to see whether it is a material weakness. Control owners, the people who run access reviews, approve changes or monitor batch jobs, perform the daily work and produce the records that later testing relies on.
- Management sets the scope and conclusion: leadership decides which IT general controls matter, what testing is enough for each risk level, and whether the 404(a) assessment is supported.
- Control owners perform and record the control: they keep approvals, review sign-offs and exception logs that show the control ran.
- Evaluators must be sufficiently objective: people who operate a control produce weaker evidence about it, so testing should come from personnel who do not run that control.
- Management documents the evidence trail: it keeps the records that let an assessor reperform the test.
- Management decides on remediation: when a control fails, management evaluates impact and owns the fix.
Confirm with your audit committee which role signs off the conclusion, and check that your testers do not also administer the systems they test.
An implementation partner such as DeployOpen can help prepare the systems, controls and evidence that management tests. In a self-hosted open-source environment, that work often includes configuring logging and access controls, building test scripts that pull user lists or change records, packaging screenshots and exports in a consistent format, and supporting retesting after a fix. The partner works inside the client's own infrastructure and reports to management. It does not evaluate the controls for the 404(a) assessment, and it does not issue any report or attestation.
- Test preparation: defining test attributes, samples and populations so each test can be repeated.
- Evidence extraction: pulling access lists, change tickets and job logs from self-hosted platforms in a documented way.
- Retesting support: rerunning procedures after remediation and recording the results.
- Tooling and documentation: building the scripts, dashboards and narratives that make evidence reproducible.
- Boundary: the partner never signs a test conclusion or represents management's assessment as independent.
Ask any partner to state in writing which tasks they perform, who receives the output and what they will not do.
The external auditor tests ICFR under PCAOB AS 2201 and assesses IT risks under AS 2110, including the IT general controls that support automated controls. For accelerated and large accelerated filers that are not emerging growth companies, Section 404(b) requires an auditor attestation on ICFR. The auditor forms its own opinion, which means it cannot simply adopt management's work without assessing its quality. Only the independent auditor issues the attestation report.
- Independent testing: the auditor selects its own samples and reperforms key procedures when it judges the evidence insufficient.
- Reliance decisions: the auditor decides how far it can use management's or internal audit's work, based on competence and objectivity.
- Attestation report: only the auditor issues the opinion on ICFR where Section 404(b) applies.
- Communication of deficiencies: the auditor reports significant deficiencies and material weaknesses to management and the audit committee.
Confirm early with your auditor which management testing they will rely on and which samples they expect to draw themselves.
Outsourcing changes who does the work, not who owns the conclusion. Most organizations can outsource test preparation, evidence extraction, retesting and documentation support, while keeping evaluation, sign-off and the decision on materiality internal. Costs depend on how many systems are in scope, how mature the existing evidence is and how often controls change. Any fee should be quoted against written deliverables.
- Usually outsourced: writing test scripts, extracting populations, preparing sample packages and rerunning tests after fixes.
- Usually retained: the conclusion, the evaluation of deficiencies and the decision to disclose.
- One-time costs: initial scoping, building test procedures and first-year evidence collection.
- Recurring costs: periodic testing, change monitoring and support through the year.
- Quote requests: ask for deliverables per system, the evidence format, retest allowances and who keeps the records.
Check that each outsourced task is described in a written scope before work begins.
Where management testing fails and how to avoid it
The most common failure is management treating an owner's own review as independent evidence. When the person who runs a user access review, change approval or batch job also signs off that it worked, SEC guidance on objectivity says the evidence carries little weight, and the weight drops further when ICFR risk is high. Fix this by assigning each ITGC test to someone who does not operate the control, such as a compliance lead, a reviewer in a separate reporting line or internal audit. Where that is impossible in a small team, document why the owner's evidence is the best available, what independent step was added (for example, the reviewer re-running a sample of the report) and how the risk was judged.
Monitoring reports fail for a different reason: they are produced every month but nobody defines what a bad result looks like. A report listing terminated users still active, or changes deployed without a linked approval, proves nothing if there is no threshold, no named reviewer and no record of follow-up. Before the year starts, write the expected result for each monitoring report, the exception types that trigger escalation, the person who must act and the time they have to close the item. Keep the signed-off reports and the follow-up tickets together. Ask your auditor which thresholds they would accept before you rely on a report.
Evidence that stops at a mid-year date also fails. If the testing period ends in the middle of the fiscal year, the assessment has a gap at year end, including changes made in the last weeks, quarter-end access reviews and any emergency access granted near the close. Plan at least one test or monitoring cycle that covers fiscal year end, and check that the population in each report runs through that date. Undocumented daily interaction is the last failure to watch. A small company with centralized controls may rely on management's daily involvement, but once there are several reporting layers or operating segments, that involvement must be recorded, dated and tied to specific controls. Confirm with your auditor whether your structure qualifies before you rely on it.
How DeployOpen scopes and prepares management ITGC evidence
DeployOpen helps management build the ITGC evidence it needs for its own 404(a) assessment, including direct tests, ongoing monitoring and self-assessments. We plan the work in a written scope, prepare the systems and evidence, and hand them over so the company's own evaluators and its external auditor can review them. Management keeps ownership of its controls and conclusions.
How we scope
- We agree in writing which applications, databases and infrastructure fall inside the ITGC scope being tested.
- We map each in-scope control to its objective and to the evaluator who will test it, including whether that evaluator is independent of the control.
- Engagements are fixed-scope, with deliverables and timelines agreed before any work starts.
How we build
- We set up evidence sources such as access reviews, change tickets and monitoring reports so they can be retrieved for a chosen testing period.
- We prepare test scripts and sampling worksheets that an independent evaluator can follow and repeat.
- We document how monitoring activities and self-assessments are performed, who performs them, and how results are recorded.
How we hand over
- We deliver the test procedures, evidence packages and monitoring records in a form management can keep as evidential matter.
- We document any deficiencies found during preparation so management can evaluate them and decide on remediation.
- We walk the internal team through the evidence so they can answer questions from the external auditor and reperform the work.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
- Retainer work can cover re-running monitoring checks and refreshing evidence before the fiscal year end assessment date.
- Ask us to confirm which parts of the scope a retainer covers before signing, since the written scope sets the boundaries.
