Open-source tools for SOX ITGC evidence: what each covers

Which open-source tools produce SOX ITGC evidence?

Open-source tools can generate and retain ITGC evidence for identity and single sign-on, access reviews, privileged sessions, change tickets, file integrity, backups and GRC tracking, but management owns the controls and an independent auditor issues the conclusion on ICFR. A finance or audit leader considering self-hosted open source to reduce tooling spend should treat each tool as a source of evidence that management must design, operate and be able to explain, not as a compliance outcome. The right answer depends on which financially significant systems are in scope, how many people hold privileged access, and how mature the company's evidence practices already are.

Start by matching each ITGC area to a candidate tool and the specific artifact the auditor will ask for. Keycloak can centralize authentication through single sign-on for applications that support OpenID Connect, OAuth 2.0 or SAML 2.0, and it can broker logins to an existing identity provider, so the reviewer needs its configuration and login records. midPoint runs access certification campaigns in which designated reviewers keep, change or revoke items within a set timeframe, which produces the review record. Teleport records SSH and Kubernetes sessions and stores recordings with audit events, while Wazuh raises alerts on monitored file changes and Bareos keeps a catalog of backup, restore and verify jobs. GLPI can hold change tickets that follow ITIL practices, and CISO Assistant tracks assessments against more than 200 frameworks.

Each tool then has to pass the test auditors apply to information produced by the company. Under PCAOB AS 1105, an auditor who relies on company-produced information must test its accuracy and completeness, or the controls over it, and judge whether it is precise enough for the purpose. Confirm with your audit firm early whether each report, such as a certification campaign export, a Teleport audit log or a Bareos restore log, can be reproduced with the same parameters and shows population completeness. Also confirm each product's license terms, such as the AGPL-3.0 or GPL versions listed in the supplied facts, with your legal team before deployment, and confirm the capabilities you need in the current release, since this page does not list them.

Which tool covers which ITGC evidence gap

Each tool below produces evidence for one slice of the four SOX ITGC areas: access, program changes, program development and computer operations. A tool only generates records; management still has to design the control, assign an owner, define the review and keep the output for the external auditor to test.

Keycloak for SSO and authentication logs

Keycloak handles access to financially significant applications, so users sign in through one identity provider instead of separate application logins. It supports OpenID Connect, OAuth 2.0 and SAML 2.0, and can broker logins to an existing identity provider. For the access area, check whether every in-scope application is actually forced through Keycloak, that local application accounts are disabled or documented, and that authentication events are retained and exported for review. Keycloak does not decide who should have access.

midPoint for access certification

midPoint runs access certification campaigns in which designated reviewers decide within a set timeframe whether to keep, change or revoke access items such as role assignments. This addresses access accumulation and segregation of duties conflicts that build up as people change roles. The evidence auditors look for is the campaign definition, reviewer assignments, completed decisions, revocations and follow-up. Confirm that the reviewers are independent of the people whose access they review and that the campaign scope covers every in-scope system.

Teleport for privileged session recording

Teleport records SSH and Kubernetes sessions by capturing full terminal output, records desktop screen and mouse input, and captures database queries and application request events. Recordings can be stored on a filesystem, in S3-compatible storage or in Google Cloud Storage, alongside audit events. For privileged access, this gives a per-session trail of who ran what on production systems. Confirm retention, who can view or delete recordings, and that recordings are protected from the administrators they monitor.

GLPI for change and ticket records

GLPI's Assistance module lets users create, follow and process tickets, problems and changes following ITIL practices, with plannings, statistics, recurrent tickets and a Kanban view. For program changes, it can hold the request, approval, testing and closure trail that auditors sample. The key checks are whether approval is required before implementation, whether emergency changes are tracked and reviewed afterward, and whether production deployments can be tied to a ticket. Ticket fields alone do not prove that the change was tested.

Wazuh for file integrity alerts

Wazuh's file integrity monitoring records a baseline of checksums and attributes for monitored files and directories, then alerts when a user or process creates, modifies or deletes a monitored file. Scans can run on a schedule or in real time and record how and when a change happened and who made it. For computer operations and change control, this supports detection of unauthorized changes to configurations and financial application files. Confirm which paths are monitored, who reviews alerts, and how each alert is matched to an approved change.

Bareos for backup and restore jobs

The Bareos Director schedules and supervises backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files. It can restore files from the current backup or from one taken before a given date and time. For computer operations, the catalog and job logs show that backups ran, verification completed and restores were tested. Auditors will also ask whether restore tests produce documented results, whether the catalog is itself backed up, and who can change retention or delete jobs.

CISO Assistant for framework and assessment tracking

CISO Assistant ships more than 200 frameworks, including SOC 2 and ISO 27001, and runs audits and assessments with automatic mapping between frameworks. It is useful for tracking which ITGC controls map to which requirements and for recording assessment status and findings. It does not test the controls itself. Confirm that the mapping is reviewed by someone who understands SOX scope, that evidence links point to the source system records, and that the tool's outputs are not treated as the auditor's conclusions.

What the AGPL, GPL and EUPL licenses mean for a self-hosted deployment

The licenses on the tools in this topic govern what your organization may do with the software, not whether the software produces acceptable ITGC evidence. Using a tool internally on your own infrastructure is generally the least restrictive situation under most of these licenses, because many obligations are triggered by distribution or, for the AGPL family, by offering modified software to users over a network. Apache-2.0 (Keycloak) is permissive and imposes light conditions such as retaining notices. The GPL-family licenses (GPL-2.0-only for Wazuh, GPL-3.0-or-later for GLPI), the AGPL-3.0 variants (Teleport and Bareos) and the EUPL-1.2+ (midPoint) each set different rules on modification, source availability and redistribution. Confirm for each component whether your deployment is internal only, whether you modify its code, and whether any user outside the company, such as a managed service provider or a customer portal, interacts with it.

Two details deserve specific attention. The AGPL-3.0 licenses include network-use provisions, so a modified Teleport or Bareos instance exposed to a provider or third party may carry source-offer duties that an internal-only install would not. Also check whether your DeployOpen-delivered customizations, connectors or hardening scripts are treated as modifications or as separate works, since that determines what you must publish or license. Ask counsel to document, per component, the license version in use, the modifications made, and the deployment boundary, and keep that record with your ITGC evidence so auditors can see the scope you assessed.

The license does not change the audit test. An assessor still asks whether access to the financially significant system was authorized, whether changes were approved and whether the report used as evidence is complete and accurate under AS 1105. License compliance is a separate legal question owned by the company and its counsel, and an implementation partner or auditor cannot give that legal opinion. Do not assume the obligations are satisfied because a tool is popular or widely deployed. Before go-live, have counsel confirm the obligations for each component in the deployment, and schedule a re-review whenever you upgrade a component, change how it is hosted or add a customization.

How auditors test reports from these tools as IPE

Under PCAOB AS 1105, an auditor who uses information produced by the company must test that information for accuracy and completeness, or test the controls over it, and must evaluate whether it is precise and detailed enough for the purpose. Auditors call this information produced by the entity, or IPE. A report from a self-hosted tool, such as an access review export or a change ticket list, is IPE the moment it supports a control conclusion. The compliance lead decides which reports are relied on, documents what each report is used for, and keeps the file that lets an auditor repeat the test. Ask the auditor early which reports they expect to rely on and what completeness test they plan, so the evidence file is built to that test rather than reconstructed later.

Report inventory: List every report used as evidence, the control it supports, the tool and version that produced it, and who runs it.
Retained configuration baselines: Keep dated copies of the settings that determine what a report contains, such as filters, date ranges and included systems.
Query and report definitions: Store the exact definitions used to produce each report so the same output can be regenerated.
Reconciliation evidence: Record how report totals agree to a source system or an independent count, and who performed the reconciliation.
Auditor walkthrough notes: Document what the auditor asked, what was provided and what follow-up was agreed.

Before fieldwork, confirm with the auditor which completeness and accuracy procedures they will accept for each report.

What to confirm before relying on a tool's output

An open-source tool can produce ITGC evidence only if its output is complete, protected, retained, reviewed independently, reproducible and governed by change control. The cards below list what to confirm with the vendor and in your own environment before an auditor sees a single report.

Captured fields match the control

Confirm that the tool records the fields the control needs, such as user identity, timestamp, action, object and outcome, and that nothing important is dropped by default. A session recorder or ticket tool may log events that look complete but omit the approver or the before-and-after values an auditor will ask for. Map each control attribute to a specific field in a test export, and confirm the vendor's documentation on what each field means. Ask the vendor to confirm the capability; do not assume it from the product description.

Logs protected from change

Audit logs and evidence stores must be protected against alteration or deletion by administrators whose actions they record. Confirm where logs are written, who holds write and delete rights, whether the storage backend supports immutability or object locking, and whether log integrity can be verified after the fact. If the tool and its logs share one administrator account, the evidence has no independent protection. Document the storage design so that testers can see who could have changed a record.

Retention covers the audit period

Evidence must still exist for the whole period the auditor tests, including any roll-forward and the prior-year comparison where the auditor relies on it. Confirm the tool's default retention, whether it can be extended, and whether backend storage lifecycle rules could delete records early. Check that backups of the tool's database and recording storage are included in the retention plan. Agree the retention period with your auditor before the first test cycle starts.

Reviewers independent of the activity

A reviewer who approves access or change activity should not be the person who performed it, and should not report to that person on the same activity. Confirm that the tool enforces or at least records reviewer identity, prevents self-approval, and keeps review history. Access certification and change approval workflows are common places where this breaks, because administrators often review their own grants. Document the reviewer assignments and the reasoning behind them.

Reports reproducible on request

Auditors often ask for a system-generated report, then test whether it is complete and accurate. Confirm that you can regenerate the same report with the same parameters, that the query or filter logic is documented, and that the output can be traced back to the source data. Ask the vendor how the report is produced and whether any data is filtered or excluded in the process. Run the report yourself before the audit and compare it against an independent source.

Tool configuration under change control

Settings that determine what a tool captures, alerts on or approves are themselves ITGC-relevant. Changes to monitored paths, audit rules, retention, role mappings or approval thresholds should go through the same change process as the systems they monitor. Confirm that configuration files are version controlled, that changes are logged with an approver, and that the tool itself is patched on a documented schedule. An unmanaged configuration change can silently remove the evidence a control depends on.

Where open-source tools need manual controls around them

A tool does not design or operate a control on its own. Under SOX, management owns the ICFR control, and the auditor tests the control as performed. A tool such as midPoint can run an access certification campaign, but the control is not operating until a named reviewer records a decision to keep, change or revoke each access item within the timeframe management set. If the campaign completes with items left unanswered, or with reviewers approving their own access, the tool has produced a report and the control has still failed. Before go-live, write down who reviews which role assignments, what the deadline is, who follows up on overdue items and how revocations are verified in the target systems.

Change management shows the same gap. GLPI can hold a change record that is approved, tested and closed, but the auditor will also ask whether the change that reached production is the one that was approved. The ticket must carry an identifier that links to the deployment record, the commit or the configuration change, and someone must check that the two match. Wazuh file integrity alerts add a second check: an unexpected modification on a monitored production file should map to a ticket or be investigated as an unauthorized change. Confirm with your team how alerts are triaged and who signs off on the disposition.

Backups need the same discipline. Bareos can run restore and verify jobs and record them in its catalog, but a job completing successfully does not show that a financially significant dataset can be restored accurately. Schedule a sample restore on a defined cadence, have the restored data reconciled to the source, and retain the signed result. Because the auditor may need to understand how the report was produced, test the tool-supported control itself: confirm the report is complete and accurate, the parameters are correct and the reviewer evaluated it. Plan for these tests as deficiencies if they are missing, because a control that exists only in the tool's configuration is hard to defend.

How a tool-based ITGC evidence program gets built

The sequence moves from choosing which systems and controls the tools will cover, through configuration and a test period, to an independent check of the tool reports and a retained evidence file ready for the external auditor. Each phase ends with a named output that the next phase depends on.

Scope the systems and controls
Management identifies the financially significant applications, databases, infrastructure and locations, then lists the ITGCs that protect them and the automated controls that depend on them. Only the IT general controls needed for the proper and consistent operation of financial reporting controls belong in this list. The output is a scoping memo that maps each tool to the control it will evidence and to the system owner responsible for it. The phase is complete when every in-scope control has exactly one named evidence source.
Configure each tool and document settings
Engineers install the chosen open-source tools inside the company's own environment and set them up for the scoped systems, such as single sign-on connections, certification campaigns, session recording, ticket workflows, file integrity baselines and backup jobs. Each configuration choice is written down with the setting name, the value and the reason for it, so an auditor can see what the control does and who approved it. The output is a configuration record and a change entry for each tool. The phase closes when a control owner has reviewed the record and signed off on it.
Test the design with a walkthrough
Before the test period starts, the control owner and a reviewer trace one transaction or access event through each tool to confirm the control works as documented. This shows the tool captures the right fields, such as requester, approver, timestamp and affected object. Any gap, such as a missing approval step or a log that omits the actor, is fixed and the configuration record is updated. The output is a dated walkthrough memo with screenshots or exported records. The phase is complete when the reviewer agrees the design meets the control objective.
Run the controls through a test period
The tools operate in production for the full period the company and its auditor agree on, with the control owners performing their normal duties, such as completing access review decisions, approving changes, reviewing alerts and checking backup restore tests. Owners keep a log of exceptions and how each one was handled. The output is a continuous set of tool records and exception logs covering the period. The phase is complete when the owners confirm the record is complete and no configuration changed without a logged approval.
Test the reports as IPE
Because the reports come from the tools, the auditor treats them as information produced by the company and will expect testing of their accuracy and completeness. An independent party, not the person who ran the tool, compares report totals against source data, checks filters and parameters, and confirms the report contains every relevant item in the period. The output is an IPE testing file for each report, showing the source, the query or parameters, the reconciliation and any exceptions. The phase closes when the tester documents that the report is reliable for the control purpose.
Remediate exceptions and close gaps
Each exception found in the test period or in the IPE testing is assessed for its effect on the control and on the financial reporting controls it supports. Where a failure is confirmed, the owner fixes the root cause, documents the fix and, if needed, identifies a compensating control. The output is an exception register with a disposition for every item and the evidence of remediation. The phase closes when management has either resolved each exception or recorded the assessment that supports leaving it open.
Retain and index the evidence file
The company stores the configuration records, walkthrough memos, tool exports, IPE files, exception registers and approvals in a controlled repository with retention rules and access limits. An index links each control to its evidence and to the tool, owner and period it covers. The output is a complete evidence package that the auditor can request and reperform from. The phase is complete when a second person can locate the evidence for any control in the index without help from the control owner.

Questions buyers ask about open-source SOX ITGC tools

Can open-source tools alone satisfy SOX ITGC requirements?

No. Open-source tools can run controls and generate evidence, but they do not make a company compliant on their own. Management owns the control design, the policies, the approvals and the conclusion on whether ICFR is effective. The tools support those controls: Keycloak can centralize sign-in, midPoint can run access certification campaigns, Teleport can record privileged sessions, GLPI can hold change tickets, Wazuh can alert on file changes and Bareos can run and log backups. Each tool still needs documented procedures, defined reviewers and records showing that people performed the reviews. The external auditor, if one is engaged, tests the controls and issues the opinion. DeployOpen prepares and configures these systems and evidence but does not issue audit reports or attestations.

How much effort does a self-hosted ITGC tool stack need from internal staff?

Internal staff remain responsible for the controls even when a partner handles the build. Expect ongoing effort from several roles: system administrators who operate and patch the tools, control owners who perform reviews and approve changes, application owners who confirm access lists, and a SOX or compliance lead who keeps the evidence index current. The effort depends on how many systems are in scope, how many users and privileged accounts exist, and how often reviews run. Ask any partner to show, in writing, which tasks it performs, which tasks remain with your staff and how the handover works.

What drives the cost of running open-source ITGC tools?

License fees are often zero for these tools, so most of the cost is labor and infrastructure. The main components are: configuring each tool and integrating it with identity, ticketing and cloud accounts; hosting and storage for logs, session recordings and backups; maintaining, patching and upgrading the platforms; testing the controls and the reports they produce; and documenting procedures and evidence for each control. Costs rise with the number of in-scope systems, the number of privileged users, the retention period for recordings and the amount of custom integration. Costs fall when identity is centralized and reviews are automated. Ask any quote to separate one-time implementation work from recurring operating work, and to state who pays for each item.

How long do setup and evidence collection take for SOX ITGC tools?

The timeline depends on scope and on the audit period the auditor will test, so no fixed duration applies. Setup covers installing and hardening the tools, connecting them to in-scope systems and writing procedures. Evidence collection then has to run over the period under test, because auditors normally need records showing a control operated consistently across that period, not only a snapshot at go-live. Access reviews, change samples and backup restore tests each produce their own records on their own schedule. Ask any partner for a written plan that ties each control to its first and last evidence date and to the interim testing your auditor expects.

Do auditors accept reports from open-source tools as IPE?

Auditors can accept them, but only after testing. Under PCAOB AS 1105, an auditor who uses information produced by the company must test its accuracy and completeness, or test the controls over those attributes, and must judge whether the information is precise and detailed enough for the purpose. A report from GLPI, Wazuh or midPoint is therefore information produced by the company, not evidence that is accepted because it came from a known product. Management should be able to show the query or configuration that produced each report, who ran it, the population it covers and a reconciliation to source data. Confirm the exact expectations with your external auditor before relying on any report.

When should a company hire an implementation partner instead of doing it internally?

Hire a partner when the internal team lacks the time or skills to build and document the controls, or when the timeline is fixed and the scope is clear enough to write down. A partner can take on platform work such as installation, integration, hardening, backup configuration and evidence preparation under a written, fixed scope. Keep these duties with management: approving access, deciding control design, performing reviews and owning the conclusion on ICFR. Keep evaluators independent of the people who built the controls where the auditor requires it. A partner that also designs your controls and then tests them should be assessed against the independence expectations your auditor applies. Ask for a written scope, deliverables and a clear list of what your team must still do.

What an implementation partner does and does not do for these tools

An implementation partner such as DeployOpen can plan, install, configure, harden, back up and document the self-hosted tools in this topic inside the company's own cloud accounts, data centers or air-gapped networks, and it can prepare the evidence those tools generate. Typical work includes setting up Keycloak as the single sign-on point with its realm and client configuration, building midPoint certification campaigns with named reviewers and deadlines, enabling Teleport session recording to the chosen storage backend, and tuning Wazuh file integrity monitoring baselines for in-scope directories. The company owns the controls. Management decides which controls exist, who performs them, what counts as an exception and how often evidence is reviewed. The partner builds what management asks for and documents how it works.

Only the company's independent external auditor issues the opinion on internal control over financial reporting under PCAOB AS 2201. Neither the partner nor the company's own staff can issue that opinion, and a partner's documentation does not replace the auditor's own testing of the reports and the completeness and accuracy of the data behind them (see the IPE discussion above). Confirm in writing which party will sign off each control, which party holds the admin credentials for each tool, and who approves changes to tool configuration, since those answers determine what the auditor can rely on.

A partner should not design and operate the controls it then tests for the same company. If the same firm configures an access review and also tests whether that review worked, the independence of the testing is weakened, and the external auditor may decline to rely on that testing. Ask the partner to separate the build work from any later assessment, and assign a named internal owner to each control before implementation starts. Management should also keep the configuration baselines, change records and vendor license terms for each tool, because those are the documents an auditor will request first.

How DeployOpen prepares SOX ITGC evidence with open-source tools

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For SOX ITGC evidence, we prepare the systems and the evidence packages that management and your independent auditor will test, while your organization keeps ownership of its controls.

How we scope

Engagements are fixed-scope, with systems, controls, deliverables and timelines agreed in writing before work starts.
We confirm which access, change, operations and backup controls the tools will evidence, and which stay with existing systems.
The written scope names the owners who will review reports, approve configurations and sign off on each control.

How we build

We deploy the identity, access review, session recording, ticketing, file integrity and backup tools in your environment.
We configure reports and logs so each population can be reproduced, filtered and checked for completeness and accuracy.
We test the tools and their reports against the control design so the evidence is ready for independent testing.

How we hand over

We deliver configuration records, control narratives, runbooks and evidence procedures that your team can repeat.
We document how each report was generated, so auditors can perform their own testing of information produced by the company.
We walk your control owners through the handover so they can run the tools and retain the evidence without us.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
We can help you prepare for the auditor's walkthroughs and respond to questions about how a report was produced.
Ask us to confirm how each tool's license terms and release cycle affect your environment before you commit to a retainer.

Open-source tools for SOX ITGC evidence