Can automated evidence collection replace manual SOX ITGC testing?
Automation can carry part of the SOX ITGC evidence load, because SEC guidance recognizes on-going monitoring as a source of evidence about whether controls operate. It cannot replace the external auditor's testing of the automated controls or of the accuracy and completeness of any system report that a control depends on. Management still has to show that the monitoring works, that the data behind each report is complete, and that the people reviewing the output are objective. Under Release 33-8810, the split between monitoring evidence and direct testing depends on the ICFR risk of each control, the period the evidence covers, including fiscal year end, and the objectivity of whoever evaluates it. Where risk is low, monitoring evidence may be sufficient on its own. Where risk is higher, expect the auditor to test directly.
For a finance or IT leader preparing a Section 404 cycle, the practical starting point is an inventory of the ITGC evidence now produced by hand, such as screenshots of access lists, exported change tickets and sign-off emails. For each item, ask three questions: which control does it support, is the control automated or does it depend on a report, and who on the team would review the output. Automated monitoring such as the file integrity monitoring in Wazuh, which records a baseline of checksums and attributes and alerts on changes to monitored files, can produce continuous records of who changed what and when. Its output still needs a documented baseline, a defined review step and evidence that the monitored scope covers the financially significant systems. Confirm these details in your own environment before relying on them.
DeployOpen plans, implements, configures and documents self-hosted open-source platforms in the client's own infrastructure, and prepares the systems, controls and evidence that an assessment will examine. DeployOpen does not evaluate the controls for the company, does not form a conclusion on operating effectiveness and does not issue an attestation. Management owns the controls and the ICFR conclusion. The external auditor alone forms the opinion under PCAOB AS 2201. Any automation project should therefore agree in writing which reports will be used as evidence, how their accuracy will be tested, which reviewer signs off on each monitoring output, and which parts of the evidence the auditor will test directly, before the first monitoring alert is treated as proof.
Which ITGC evidence can automated tools produce?
Automated tools can generate several kinds of ITGC evidence without a person pulling it by hand each quarter. Each source below records a different slice of activity, and each leaves a gap the auditor still needs filled. Check every card against the auditor's test plan before assuming a tool's output will be accepted as evidence.
File integrity monitoring records
File integrity monitoring takes a baseline of checksums and attributes for the files and directories you select, then alerts when a user or process creates, modifies or deletes one of them. Alerts can run in real time or on a schedule, and they record how and when a file changed and who changed it. For SOX ITGC work, this helps show that changes to financially significant configuration files were visible and reviewed. The auditor still needs the review record, showing who examined each alert, what they concluded and how unauthorized changes were handled. Confirm which paths your scope covers before relying on the baseline.
Automated application control outputs
Where an application control is fully automated, such as a system-enforced approval limit or a validation rule, the auditor may test it through a benchmarking strategy rather than sampling many individual transactions. That relies on the control being consistently applied, which is why the auditor will still test the ITGCs that keep the logic stable. Automated tools can record configuration and change status for these controls. Ask the auditor whether they accept a benchmark for your controls, and confirm which system versions and parameters the benchmark covers.
Scheduled job and backup logs
Job schedulers and backup tools write logs showing which jobs ran, when they finished, whether they succeeded and where backups were stored. These logs support computer operations controls such as completeness of processing and recoverability. The log itself is not proof of accuracy, though. An auditor using system-generated reports must test the accuracy and completeness of those reports, so keep the log's source and retention settings documented. Ask the auditor which reports they will treat as information produced by the company.
Access and change records from ticketing systems
Ticketing systems hold the request, approval, implementation and closure record for access grants and program changes. They show who approved each change and when it moved through each step, which feeds the testing of authorization and separation of duties. Tickets alone do not show that the approved change is what reached production. Pair the ticket record with a monitoring or deployment record that shows the actual change, and confirm that tickets cannot be closed by the same person who requested them.
Recurring configuration checks
Scheduled configuration checks compare current settings against a documented standard, such as password policy, logging enablement or privileged group membership, and record any drift. They are a form of ongoing monitoring that can run frequently and produce a dated history. The SEC guidance treats recurring monitoring as potentially sufficient evidence when risk is low, but it still expects the evaluators to be objective and the period to cover the year. Confirm who owns the standard, who reviews exceptions and how the check's own rules are tested.
How auditors test automated controls and system reports
Automation can carry a larger share of SOX ITGC evidence, but the external auditor decides how much of that evidence counts. Under PCAOB AS 2201, paragraph B28 notes that entirely automated application controls are generally not subject to breakdowns caused by human failure. That observation is the basis for a benchmarking strategy: the auditor tests the automated logic once, confirms it is unchanged, and relies on that result for the rest of the period. The strategy only holds if the IT general controls around the control are effective. Program change controls must show that the configuration tested is the one running in production, and access controls must show that no one with change rights altered the logic during the year. Before planning a benchmark, confirm with your auditor which change and access evidence they will need to support it, and who in your team owns each piece.
A system-generated report is a different problem. PCAOB AS 1105, paragraph 10, requires an auditor who uses information produced by the company to test its accuracy and completeness, or the controls over those attributes, and to evaluate whether the information is precise and detailed enough for the purpose. Staff Audit Practice Alert No. 11 applies this to automated controls: when a selected control relies on system-generated data or reports, the auditor tests both the control and the controls that make the data or report accurate and complete. In practice, a monitoring alert, an access review export or a file integrity log is only as strong as the parameters, population and query behind it. Document the report's logic, the data source, the filter criteria and who can change them, and be ready to show that the report captured every relevant record in the period.
Sufficiency is the auditor's judgment, not a property of the tool. Neither the vendor of a monitoring product nor an implementation partner can declare that its output satisfies Section 404, and the SEC's guidance leaves the weighing of evidence quality, sample size, period covered and evaluator objectivity to management and the auditor. A tool that generates clean reports can still fail if the report omits a population, if the baseline was set after the period began, or if the administrator who configures alerts is also the person reviewing them. Ask your auditor, early in the year, to walk through the specific reports and automated controls you intend to rely on, and decide in advance which items will also receive manual testing.
Where automation fits by control situation
A fully automated application control performs the same logic every time it runs, so the audit question shifts from whether people performed it correctly to whether the logic and its configuration stayed the same during the period. PCAOB AS 2201 notes that entirely automated application controls are generally not subject to breakdowns from human failure, which is the basis for a benchmarking strategy: if the underlying IT general controls over program changes and access are effective, the auditor can test the control's configuration once and rely on it across the period. Automation evidences this well, because a monitored configuration baseline with alerts on change shows that the logic did not move. Direct testing still matters for the initial test of the logic, for the period in which a change occurred, and for the access rights that could alter the configuration.
- Configuration baseline: Record the control's settings and code at the start of the period and alert on any change, so the auditor can see the logic was stable.
- Change linkage: Match each detected change to an approved change ticket, since an unapproved change breaks the benchmarking basis.
- Access to the logic: Show that only authorized roles can edit the configuration or the code that performs the control.
- Direct test of logic: Have the auditor or an independent tester run known inputs through the control and compare the output to expected results.
- Period coverage: Confirm monitoring ran across the full period, including any gaps caused by agent outages.
Confirm with your auditor whether they plan a benchmarking approach for each application control before you build the evidence set.
Many financial controls still depend on a person reviewing, approving or reconciling something, and automation cannot prove that the judgment was sound. Here monitoring supports the control in a narrower way. SEC Release 33-8810 describes on-going monitoring as recurring management activities, such as self-assessment procedures and analysis of performance measures designed to track whether controls operate. Automated tools can show that a review step happened on time, that the approver was authorized, and that the workflow was not bypassed. They cannot show that the reviewer examined the right items with enough skill. Evidence sufficiency depends on quantity, such as sample size, and on the procedures used, the period covered and the objectivity of the evaluators, so direct testing remains necessary.
- Workflow timestamps: Show that approvals occurred within the period and before posting, which tools can log reliably.
- Approver authority: Match approvers to a current authorization list, which an access review can supply.
- Bypass detection: Flag transactions posted without the required approval step.
- Reviewer evidence: Retain the review workpaper or sign-off that shows what was examined, since logs alone do not prove the review was meaningful.
- Direct testing: Plan sample-based testing by the auditor or an independent evaluator, covering the full period including fiscal year end.
Ask the auditor how much of the sample they will accept from monitoring and how much must come from direct testing for each manual control.
When a control uses a report produced by a system, such as an aged receivables listing or an exception report, the report itself becomes part of the audit evidence. PCAOB AS 1105 requires an auditor who uses company-produced information to test its accuracy and completeness, or the controls over those qualities, and to judge whether it is precise and detailed enough. Staff Audit Practice Alert No. 11 adds that supporting a control that uses system-generated data means testing both the control and the controls over the data or report. Automation can help by monitoring the query, parameters and output of the report generation, and by alerting when the report logic or source tables change. It does not, by itself, prove that the report is complete, so the team still needs reconciliation or a completeness check against the source.
- Report logic monitoring: Track changes to the query, script or report definition, and keep a baseline so the auditor sees what produced the output.
- Parameter control: Record the date range and filters used for each run, since a wrong parameter can exclude items silently.
- Completeness check: Reconcile report totals to the source system with an independent count or control total.
- Output integrity: Retain the report as produced, with a hash or equivalent, so it cannot be altered after the fact.
- Independent recalculation: Have the tester recompute a sample of report figures from source data.
Ask the auditor which reports they will treat as information produced by the company and which controls over those reports they expect to see tested.
How to build automated ITGC evidence that holds up
This sequence turns automated monitoring into evidence an external auditor can rely on, by tying each automated control to its ITGC area, documenting the baseline, proving the reports are complete and accurate, and keeping the record through fiscal year end.
Map each automated control to its ITGC area
Start with the list of automated controls management relies on for financial reporting, then assign each one to an ITGC area: access to programs and data, program changes, program development, or computer operations. Confirm which application, database, or infrastructure component the control depends on, since a monitoring tool only evidences what it watches. The output is a control-to-area register that names the system, the owner, and the financial reporting risk the control addresses. Only controls that support proper and consistent operation of financial reporting controls belong in this register.
Establish and document the monitoring baseline
For file integrity or configuration monitoring, record the approved starting state of each monitored file, directory, or setting before relying on alerts. Document what was captured, when, by whom, and how the baseline itself is protected from unauthorized change. Wazuh file integrity monitoring, for example, records checksums and attributes of monitored items and alerts on creation, modification, or deletion, so the baseline defines what counts as an exception. The output is a signed-off baseline record and a scope statement listing every monitored location.
Define alert ownership and review cadence
Assign a named reviewer for each alert stream, state how often reviews occur, and define what counts as an exception that needs investigation. Management's ongoing monitoring is a recurring activity, so the review cadence should be written down and kept consistent across the period. Record how a reviewer disposes of each alert, whether it was a authorized change, an unauthorized change needing remediation, or a false positive with a documented rationale. The output is a review procedure and a disposition log showing who reviewed what and when.
Test completeness and accuracy of each report
Any system-generated report used as evidence needs testing on its own, because the auditor will test the control and the controls over the data or report. Confirm the report includes all relevant records, such as every monitored host or every privileged account, by reconciling it to an independent source. Confirm the data is accurate by tracing sample items to source systems, and confirm the parameters and filters used to generate the report are fixed and documented. The output is an information-produced-by-the-entity test file with the reconciliation, the parameters, and any exceptions resolved.
Assess whether the report is precise enough
Beyond completeness and accuracy, evaluate whether the report is detailed enough to reveal the exception the control is meant to catch. A summary count of changes may hide a single unauthorized modification that a detailed event log would show. Document the level of detail required for the control's purpose and confirm the report provides it, including the user, the time, and the object changed where the control depends on those fields. The output is a short precision assessment for each report, signed by the control owner.
Retain outputs for the full period
Keep baselines, alert logs, review sign-offs, and the report test files for the entire period under evaluation, including fiscal year end, since the evaluation ordinarily considers evidence from a reasonable period during the year. Confirm retention settings in each tool so logs are not overwritten before the period closes, and store copies in a location with restricted write access. Ask the auditor early which retention periods and sampling dates they expect. The output is a retained evidence index mapping each control to its artifacts by date.
Document the evaluator's independence
Record who performed each review and test, their reporting line, and whether they operate the system they are evaluating. Evidence from people who run the control carries less weight than evidence from evaluators who are objective, so separate the operator from the reviewer where practical. If an implementation partner or co-sourced internal audit team performed any testing, document its competence and objectivity and its scope. The output is an evaluator independence memo included in the evidence package, which the external auditor can read before deciding how much reliance to place on the automated evidence.
Where automation still needs testing
Automated monitoring produces evidence only as far as the monitoring itself is trustworthy. Each card below names a way automated evidence fails quietly, the control to add so the gap is closed, and the question an auditor is likely to ask. Together they show that the monitoring tool, its baseline, its reports and its administrators all need testing before their output counts.
Baseline accepted without review
A file integrity or configuration baseline records whatever state the system was in when monitoring started. If nobody checked that starting state, an unauthorized change made before go-live becomes the reference point and never raises an alert. Add a documented, reviewed baseline approval that compares the recorded state with the approved configuration and is signed by someone outside the team that runs the system. The question an auditor will ask is who approved the baseline, against what, and on what date. Wazuh's file integrity monitoring works by recording a baseline of checksums and attributes for monitored files and directories, so confirm the baseline contents and approval for each in-scope system.
Alerts that nobody reviews
An alert that is generated but never triaged gives no assurance that a change was authorized. Automated tools often send alerts to a shared mailbox or channel where they are ignored over time. Add a defined review procedure that assigns each alert class to a named owner, sets a review cadence, and requires a documented disposition for every alert, including the ones closed as expected. The auditor will ask for a sample of alerts from the period, the disposition of each, and evidence that the reviewer was independent of the change being reviewed.
Reports whose logic changes silently
System-generated reports used in a control, such as a user listing, a terminated-employee comparison or a change log extract, depend on filters, date ranges and joins that someone can edit. A changed filter can drop records without any visible sign. Add change control over report definitions, a reconciliation of report totals to the source system on a sample basis, and a record of who last modified each query. Staff Audit Practice Alert No. 11 says that when a control relies on system-generated data or reports, the auditor tests both the control and the accuracy and completeness of that data, so the auditor will ask for the report parameters and the reconciliation.
Configuration drift outside monitored scope
Monitoring covers the directories, hosts and settings someone put in scope. Changes made to systems outside that list, such as a new container image, a cloud security group or a database parameter, never reach the monitor. Add a periodic scope review that compares the monitored inventory with the current list of financially significant systems, and document each addition or exclusion with a reason. The auditor will ask how the company knows the monitored population is complete, and will look for the scope review as the evidence that answers it.
Administrators who can alter logs
If the people who administer a monitoring tool can also edit its alerts, its stored history or its agent configuration, the tool cannot be relied on to show what they did. Add restricted write access to log stores, forwarding of security events to a separate repository that administrators cannot modify, and periodic review of changes to the monitoring configuration itself. The auditor will ask who can change or delete monitoring data, whether those changes are logged elsewhere, and how the company confirms that the tool still runs as designed. Confirm these capabilities with the specific product and deployment before relying on them.
Who owns the automated controls and who tests them
Management remains responsible for internal control over financial reporting, including every automated control and the monitoring that supports it. Under SEC guidance, on-going monitoring is management's own recurring activity, so a tool running in the environment does not transfer that responsibility. Management must decide which controls the monitoring covers, who reviews the output, how exceptions are investigated, and how the review is documented and retained.
- Control ownership: Name an owner for each automated control and for each monitoring alert or report that serves as evidence.
- Review performance: Show that someone with authority reviews alerts and reports on a defined cadence, and records what was found and how it was resolved.
- Monitoring design: Decide which files, configurations and accounts are monitored and document why those are the ones tied to financially significant systems.
- Retained evidence: Keep the review sign-offs, exception tickets and the raw outputs that the reviewer relied on.
- Periodic assessment: Evaluate whether the monitoring itself still operates as designed after system changes.
Before relying on any automated control, confirm with your auditor which parts of the monitoring they expect management to test directly.
An implementation partner such as DeployOpen can plan and configure self-hosted monitoring inside the client's own infrastructure, prepare system-generated reports, and document how the evidence is produced. The partner's work supports management's controls. It does not replace them, and it does not attest to whether the controls operate effectively.
- Configuration: Set up monitoring agents, baselines, alert rules and retention settings as agreed in a written scope.
- Report preparation: Build the reports and queries that management reviews, and document their logic, parameters and data sources.
- Evidence documentation: Write procedures that explain how each report is generated, who runs it, and how its completeness is checked.
- Change control over the tooling: Route changes to the monitoring configuration through the same approval process the client uses for financially significant systems.
- Knowledge transfer: Train the client's staff so they can run and explain the monitoring after the engagement ends.
Do not treat a partner's configuration documents as a substitute for management's own review evidence, and confirm in the statement of work which deliverables are yours to keep.
The external auditor tests the controls under PCAOB AS 2201 and assesses the IT risks under AS 2110. When the auditor relies on system-generated data or reports, AS 1105 requires testing their accuracy and completeness, or the controls over them, and Staff Audit Practice Alert No. 11 calls for testing both the control and the data behind it. The auditor forms and issues the opinion on internal control.
- Control testing: Test the monitoring and review controls directly, or rely on ongoing monitoring where risk is low and the evidence is sufficient.
- Report testing: Test the accuracy and completeness of the reports management uses, including the parameters and the source data.
- Independence: Assess whether any party that configured or tested the controls was also the one evaluating them.
- Sufficiency judgments: Decide whether sample sizes, the testing period and the evaluators' objectivity are adequate.
- Opinion: Issue the attestation report, which no implementation partner can issue.
Agree the auditor's testing approach for automated evidence early, before the monitoring is relied on for the period under audit.
Questions buyers ask about automating SOX ITGC evidence
Can automated monitoring replace all manual SOX ITGC testing?
No. Automation can carry a larger share of the evidence load, but it rarely removes testing entirely. SEC guidance on management's evaluation says evidence of operating effectiveness can come from direct testing, ongoing monitoring or both, and that its sufficiency depends on the procedures used, the period covered, sample size and the objectivity of the people performing the work. Monitoring can supply much of that evidence for some controls, especially where ICFR risk is low, but the company still has to decide which controls qualify, cover the fiscal year end and show that the monitoring itself works. Ask your auditor which controls they will accept on monitoring alone before you redesign your testing plan.
How do auditors treat system-generated reports used as evidence?
Auditors treat a system report as evidence only after they know it is accurate and complete. Under PCAOB AS 1105, an auditor who relies on information produced by the company must test its accuracy and completeness, or test the controls over those qualities, and judge whether the report is detailed enough for the purpose. Staff Audit Practice Alert No. 11 adds that when a control depends on a system report, supporting the control means testing both the control and the controls over the report's data. In practice, the report's query logic, parameters, data source and extraction date all become part of what gets tested.
Is output from an open-source monitoring tool acceptable audit evidence?
It can be, but the tool's license does not decide the question. Auditors ask whether the tool's output is complete, accurate and unaltered, and whether the company can show that it operated throughout the period. For example, a file integrity monitoring tool such as Wazuh (GPL-2.0-only) keeps a baseline of checksums and attributes, then alerts on file creation, modification or deletion with details of who changed what and when. That output still has to pass information produced by the entity testing: the company must show the configuration covers the right directories, that logs are retained and protected, that alert review is performed and documented, and that the reports are generated from a controlled source. Confirm the exact capabilities and retention settings in your own environment before you rely on them.
What does automation need from internal staff?
Automation shifts work toward internal staff rather than removing it. The company must name owners for each automated control, define what a valid alert or report looks like, and set a review routine that someone performs and records. Staff also need to maintain the tool configuration, approve changes to monitored scope, investigate exceptions and keep the baseline current after authorized changes. Finance and IT control owners need to understand what the reports show so they can explain them to auditors. Ask any implementation partner which of these duties they would take on and which must remain with your employees, because management keeps responsibility for the control either way.
How long does it take to get automated evidence ready for an audit?
No researched timeline for this work is available to us, so the honest answer is that the duration depends on your environment and on the auditor's acceptance of your approach. Ask your external auditor, before any build starts, which automated controls they will accept, what period of history they expect to see and whether they want a pilot cycle. Then ask any partner for a written schedule that covers configuration, baseline capture, a period of operation and a test of the reports themselves. Most of the elapsed time usually comes from accumulating operating history, not from installing software.
What drives the effort and cost of automating SOX ITGC evidence?
The main drivers are the number of in-scope systems, the number of controls you plan to automate, and how much of the scope your auditor will accept on monitoring. Each new system adds configuration, report testing and a review routine. Costs are both one-time, covering design, setup, documentation and the first test cycle, and recurring, covering review, tool maintenance, upgrades and periodic re-testing. Effort rises when logs are spread across tools, when reports rely on manual spreadsheet steps, or when the company lacks a single owner for scope changes. When you request a quote, ask for the work split between design, build, report testing and ongoing support, and for the assumptions behind each line.
How DeployOpen prepares automated ITGC evidence
DeployOpen is a Chainscore Labs company that plans, implements, hardens and documents self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For SOX ITGC automation, that means the monitoring, baselines, report logic and evidence packs are built in the client's environment and handed over with documentation the company's own team can run. Engagements are fixed-scope: the systems in scope, the monitoring rules, the deliverables and the timeline are written down and agreed before any work starts, so management and the external auditor can see exactly what each automated control covers.
In practice, the work usually centers on a few decisions. The team can deploy monitoring such as file integrity tooling, set the baseline for the monitored configuration and program directories, define which changes raise alerts and who receives them, and build the scheduled reports that management reviews. Each report needs documented parameters, a stated period and a record of who reviewed it and when. Before an evidence pack goes to the auditor, confirm with your external auditor which populations, date ranges and report fields they will rely on, because the completeness and accuracy of each report must be shown separately from the control it supports. DeployOpen does not decide whether a control is effective and does not issue audit reports, attestations or certifications. Those judgments belong to management and the independent auditor.
Ongoing support is available as a retainer for monitoring tuning, upgrades, baseline reviews and periodic evidence refreshes between audit cycles. Ask any implementation partner to state in writing which parts of the work are one-time setup and which recur, who holds administrative access to the monitoring platform, and how changes to the monitoring configuration are themselves approved and logged. Those answers determine whether the automated evidence will hold up under testing of the report and its underlying data.
