Open-source tools for SOC 2 controls and evidence

Which open-source tools for SOC 2 controls and evidence fit your environment

When a customer or contract asks for SOC 2, open-source tools can produce much of the evidence auditors test, but the organization owns its controls and only an independent CPA firm issues the SOC 2 report. Your job is to choose tools that generate reliable records for the controls in your system boundary, then hand those records to the auditor. The right set depends on four things: the system boundary you define, the identity provider you already run, the cloud platform hosting the in-scope systems, and the edition limits of each candidate. A tool that covers logging for a single application may say nothing about production access in a second cloud account. Start by listing every system that stores or processes in-scope customer data, then map each control area (identity and MFA, logging, access reviews, secrets, vulnerability scanning, change control and GRC tracking) to a named owner and a named tool.

Edition limits deserve attention early. Some free tiers omit features that auditors ask for, such as approval workflows, audit logs or role-based administration, and licenses differ in what you may modify or redistribute. Ask each vendor, and confirm in your own environment, which features are included in the edition you plan to run, and whether the audit logs your auditor will sample are retained in that edition. Record the decision, the version you deployed and the evidence each tool exports, because the auditor will ask how each record was produced and whether it was complete over the observation period.

Which tools cover the controls auditors test most

SOC 2 auditors test a small set of control areas again and again: who can sign in, who can see logs and alerts, who still holds access, where secrets live, how vulnerabilities are found and how changes reach production. The cards below pair each area with an open-source tool, the evidence it can produce and the points your assessor will ask you to confirm.

Identity and single sign-on

Keycloak puts one login in front of your applications, so users authenticate once and the identity provider, not each app, decides who gets in. It supports OpenID Connect, OAuth 2.0 and SAML 2.0 and can broker logins to an existing identity provider. This supports the logical access criteria in CC6, especially user authentication and multi-factor enforcement. Confirm that every in-scope application actually redirects to Keycloak, since a local login left behind creates an exception.

Logging and detection

Wazuh collects logs, decodes them and compares each event against a ruleset of over 3,000 built-in rules and decoders plus your custom rules. Matching events are written to alerts files and shown in the dashboard, with alerts mapped to MITRE ATT&CK. This maps to the monitoring and anomaly detection expectations in CC7. Confirm log retention, alert review records and who acts on each alert, because an assessor will sample both the alerts and the follow-up.

Access certification reviews

midPoint runs access certification campaigns in which named reviewers decide within a set timeframe whether to keep, change or revoke each access item, such as a role assignment. Those decisions counter access build-up over time and support segregation of duties. This supports the periodic access review expectations in CC6 and the user access management work in CC5. Confirm that reviewer decisions and revocations are recorded with dates, and that the campaign covers every in-scope system.

Secrets management

OpenBao stores secrets encrypted in one place and can generate dynamic, short-lived credentials for systems such as databases. Each credential carries a lease that revokes it automatically on expiry, and single secrets or whole credential trees can be revoked on demand. This supports the restricted access and key protection expectations in CC6. Confirm which systems still hold static credentials outside the vault, because those fall outside the controls an assessor will test.

Vulnerability scanning

Greenbone Community Edition runs the OpenVAS scan engine against target systems, executing vulnerability tests from the Greenbone Community Feed, which is updated daily. A manager component schedules scans and stores results. This supports the vulnerability monitoring expectations in CC7. Confirm scan scope, scan frequency and how findings are triaged and closed, since the auditor will test remediation as well as the scans themselves.

Change control in source hosting

GitLab Community Edition supports protected branches that restrict which roles can push or merge, block direct pushes by setting push access to no one, and keep force pushes disabled unless explicitly allowed. Together these settings enforce a reviewed path to production. This supports the change management criteria in CC8. Confirm that approval records are kept for each merge and that branch protection is enforced on every repository in scope, because free editions may lack some approval controls.

GRC tracking and assessment

CISO Assistant is a self-hosted GRC tool that ships more than 200 frameworks, including SOC 2, and runs audits and compliance assessments with automatic mapping between frameworks. It gives you one place to track control status, owners and evidence for the CC criteria. This tool organizes evidence and does not itself satisfy any criterion. Confirm which features sit in the AGPL community edition and which require a paid edition, and confirm that the mapping is reviewed by you, not assumed.

How Keycloak and Wazuh produce access and detection evidence

Keycloak and Wazuh give an assessor two of the most direct pieces of evidence for SOC 2 access and monitoring: a single place that shows who can authenticate, and a record of how security events were detected and reviewed. With Keycloak (Apache-2.0) providing single sign-on, users authenticate with Keycloak rather than separately with each application, so the realm's user list, role assignments and login events become one set of records to sample. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, and it can broker logins to existing OpenID Connect or SAML 2.0 identity providers, so your current corporate directory can remain the source of identity while Keycloak becomes the point where authentication is enforced and logged.

Wazuh (GPL-2.0-only) supports the monitoring side. It decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders plus your custom rules, writes matching alerts to alerts.log and alerts.json, maps alerts to MITRE ATT&CK, and forwards them to the Wazuh indexer for review in the dashboard. The ruleset is only as useful as the sources feeding it, so confirm which Keycloak and host logs are collected, and which rules your team has tuned or disabled. The Wazuh ruleset documentation is the natural starting point for that check.

Neither tool produces a passing control on its own. Confirm that MFA enforcement is configured in Keycloak for the user populations in scope, and document which exceptions exist. Set log retention periods in Wazuh that match your policy and the period the auditor will sample, and write down who reviews alerts, how often, and how a reviewed alert is closed out. An auditor testing operating effectiveness over a Type 2 period will look for those reviews occurring consistently, not only for the tools being installed. Decide with your implementation partner and auditor which capabilities this scope requires before deploying, so the evidence matches the control description.

Where free editions and licenses limit SOC 2 evidence

Several tools in this group are licensed under copyleft terms such as GPL-2.0-only, AGPL-3.0 and EUPL-1.2+. These licenses let you run, study and modify the software, but they attach conditions to redistribution and, in the AGPL case, to offering the software over a network. For a SOC 2 program, the license matters less for internal use than for how you package, host and support the tool, and whether a vendor's commercial edition adds features you need.

Wazuh (GPL-2.0-only): The ruleset and alert pipeline are available under the license, but check which dashboard, reporting and clustering features ship in the edition you deploy.
Greenbone Community Edition (AGPL-3.0-or-later): The scan engine and Community Feed are available, but the feed is a separate update channel that you should confirm for your use.
midPoint (EUPL-1.2+): Access certification campaigns are part of the product, but confirm which connectors and reporting exports are included in the version you select.
Obligations you carry: If you modify an AGPL component and make it available to users over a network, you may need to offer them the corresponding source. Ask counsel to review your deployment model.
Edition limits: A feature listed in a vendor's documentation may belong to an enterprise tier. Confirm each feature against the edition you intend to run.

Before choosing, map each copyleft tool to the evidence it must produce and confirm that the features behind that evidence exist in the edition you will operate.

Why no tool can make a SOC 2 compliant

No tool can make an organization SOC 2 compliant. A SOC 2 examination tests whether the organization's own controls are designed suitably and, in a Type 2 report, operated effectively over a period. Management owns those controls, decides how they work and answers for them. Keycloak, Wazuh, OpenBao, Greenbone, GitLab and a GRC tool such as CISO Assistant can enforce settings, record activity and store records, but each one only produces evidence about a control that the organization has designed and runs. A product that is installed and switched on has not yet passed anything.

The Journal of Accountancy reported in February 2026 that SOC tool vendors may promise compliance in weeks or even hours. The word compliance is not used in SOC 2 examinations, and most of these providers are not CPA firms, so they cannot attest that controls are effective. Treat any vendor claim of a fast or guaranteed SOC 2 as a question to examine, not an outcome to buy. Ask which parts of the work are software, which are consulting, and who signs the report. Confirm the answer in writing with the vendor and with the CPA firm you intend to use.

How tool evidence moves from setup to the auditor's sample

This sequence turns each tool's configuration and output into records the CPA firm can select, test and trace back to a named control. Each step closes with an artifact the organization owns, so the auditor's sample draws from evidence that was kept as the control ran rather than rebuilt for the audit.

Map each control to a tool and owner
The control owner and the security or compliance lead work through the control matrix and record, for each criterion, which tool performs the control, which person is accountable for it, and which report or log proves it ran. Gaps where no tool exists are flagged here, along with the manual procedure that will cover them. The output is a matrix row per control that names the tool, the owner, the evidence type and the review cadence. The step is done when every in-scope criterion has a row and no row lacks an owner.
Configure each tool to the documented control
The platform team configures each self-hosted tool to match the written policy, such as enforcing MFA through Keycloak, setting alert rules in Wazuh, or applying protected branch settings in GitLab Community Edition. Configuration is kept in version-controlled files where the tool supports it, so changes carry an author and a date. The output is a baseline configuration per tool that matches the policy. The step is done when a test user or test change confirms the setting takes effect as written.
Confirm the control operates before the observation period
Before the Type 2 window starts, the team runs each control once in a controlled way and checks that the tool produces the expected record. Examples include a failed login that appears in the Wazuh alerts file, or a direct push that the branch protection blocks. Failures are fixed and the configuration is re-checked. The output is a short dry-run record for each control, showing the test, the result and the date. The step is done when every control has produced the record it will be sampled on.
Run controls and collect records throughout the period
During the observation period, the tools run continuously and the owners perform the periodic activities, such as quarterly access certification campaigns in midPoint or scheduled scans in the Greenbone scanner. Owners log exceptions, such as a failed scan or an access item that was revoked late, with a ticket and a note on what happened. The output is a dated stream of tool records and exception tickets for each control. The step is done when the owner confirms the activity occurred on schedule or documents why it did not.
Export and retain evidence in a fixed structure
At agreed intervals, the compliance lead exports reports, logs, campaign decisions and configuration snapshots from each tool and stores them in a single evidence repository. Each file is named by control ID and date, and the export method is written down so the auditor can ask how a report was produced. Retention rules set by the organization apply to every item. The output is an indexed evidence library mapped to the control matrix. The step is done when a reviewer can find the evidence for any control from its ID alone.
Review evidence internally before the audit
Someone who did not run the control checks each evidence set for completeness, consistency with the policy, and open exceptions. Gaps and unexplained exceptions are corrected or documented before the auditor sees them, and the review is signed and dated. The output is a review log with findings and their resolution. The step is done when every exception has either a remediation record or a documented explanation approved by management.
Hand samples to the CPA firm
When the CPA firm issues its evidence requests, the compliance lead provides the samples the firm selects, mapped to control IDs and accompanied by the export procedure and the configuration baseline. The firm performs its own testing and decides what it can rely on. Only the CPA firm forms the opinion on operating effectiveness, and the organization's tooling supports that work without replacing it. The output is the sample package and the firm's written requests and responses. The step is done when the firm confirms it has what it needs for each sampled control.

What must be in place before the tools produce usable evidence

A tool only produces evidence an auditor can use when the boundary, ownership and rules around it are already written down. The six items below are the groundwork each open-source control depends on, and each one includes a practical way to check it internally before the auditor asks.

Defined system boundary

Write down which services, environments, accounts, data stores and people are inside the SOC 2 system. Every tool in this topic only matters for the systems it can see, so a log collector pointed at the wrong cluster or an access review that skips a production database will leave gaps the auditor finds. To check, list every production component and confirm each one has a named tool feeding its logs, access records and scan results.

Written and approved policies

Access control, logging, vulnerability management and change management each need a policy that states the rule the tool enforces. Auditors compare what the tool does against what management said it would do, so a policy requiring quarterly access reviews must match the midPoint campaign actually configured. To check, pick one policy per tool and confirm the configured setting matches the wording, with an approval date and owner on the document.

Named control owners

Each control needs a person accountable for running it, reviewing its output and answering the auditor's questions. A tool with no owner tends to drift: alerts go unread, scan exceptions pile up and access campaigns are left open. To check, ask whether each control in the matrix names one individual, whether that person has the access needed to act, and whether a backup owner is listed for absences.

Retention settings for logs and scans

Logs, alerts, scan reports and access certification results must be kept long enough for the auditor to sample them across the full observation period in a Type 2 examination. Default retention in many tools is short or unset, and rotation can silently delete the records you need. To check, confirm the retention period configured in each tool, confirm the storage location is inside your boundary, and test that you can still open a record from the start of the period.

Documented review cadence

Set and record how often each control runs: daily alert triage, scan schedules, quarterly access certifications, and periodic review of exceptions and firewall or identity settings. Auditors test whether the control ran as often as management said it would, so an unrecorded cadence is treated as no cadence. To check, compare the calendar of runs in each tool against the schedule in your control descriptions and keep a dated record of each review.

Tool-to-criterion map

Build a single table that lists each tool, the criteria it supports (for example CC6 for access, CC7 for monitoring and vulnerability scanning, CC8 for protected branch change control) and the evidence it produces. This map is what lets you show the auditor where each piece of evidence comes from. To check, pick three random criteria and confirm you can trace each one to a named tool, a configuration and an exported record.

Who owns controls, who configures tools and who attests

Your organization owns the controls. The open-source tools generate logs, alerts, scan results and access records, but the policies, approvals and decisions behind them remain with management. An auditor will ask who made each decision, when it was made and what record shows it.

Control ownership: Name an owner for each control in your control matrix, including the access controls under CC6.1 and the monitoring controls under CC7.1, and record who approves changes to how each control works.
Access approvals: Approve joiners, movers and leavers in your identity provider, and make the keep, change or revoke decisions in midPoint access certification campaigns within the timeframe you set.
Alert review: Triage Wazuh alerts from the dashboard or from alerts.log and alerts.json, document how each alert was dispositioned, and escalate real incidents under your incident response procedure.
Scan results: Review Greenbone findings, assign remediation owners, and record any risk acceptance in writing when a finding is not fixed within your own deadlines.
Secrets and repository settings: Own the OpenBao policies and the GitLab protected branch settings, because these configuration choices are management decisions that the auditor will test.

Before fieldwork, confirm that each named owner can explain their control in plain language and can show the record they produced in the last period, because the auditor will test that person's work and not only the tool's default settings.

Questions buyers ask about SOC 2 tools and evidence

Can we run a SOC 2 with only open-source tools?

Yes, open-source tools can run many of the controls a SOC 2 auditor tests, but no tool makes a SOC 2 by itself. The organization owns its controls, and the auditor decides whether those controls were designed suitably and, for a Type 2 report, operated effectively over a period. Open-source tools such as Keycloak for single sign-on, Wazuh for log detection, midPoint for access certification, OpenBao for secrets, Greenbone for vulnerability scanning and GitLab for protected branches each produce records an auditor can sample. The gaps are usually in policy, ownership, review cadence and evidence retention, which no tool supplies. Confirm with your auditor, before you buy anything, which evidence formats and sample sizes they will accept.

What does SOC 2 tooling cost compared with the audit itself?

Open-source licenses have no fee, so most tooling cost is labor and infrastructure. The cost components are the people who deploy, integrate and operate each tool, the hosting in your own cloud accounts or data center, backup and upgrade work, and the audit fee paid to the CPA firm. Setup costs are largely one-time, while hosting, patching, rule tuning and access reviews recur every review cycle. Costs rise with the number of systems in scope, the number of identity sources, and whether you need paid editions for features such as advanced workflows. Ask any partner for a quote that separates license costs, implementation labor, hosting and recurring operations, and ask your auditor for their fee in writing.

How much internal effort do these tools need after go-live?

Effort after go-live is driven by how often evidence must be produced and how much tuning the tools need. Access reviews, joiner and leaver checks, alert triage, vulnerability scan follow-up and change approvals recur throughout the observation period of a Type 2 report, so someone must own each one. Security monitoring usually needs the most tuning, because default rules generate alerts that must be reviewed and documented. A realistic plan names an owner for each control, a review calendar and a backup of the evidence. Confirm with your team lead how many hours each recurring control needs before you commit to a schedule.

Does a GRC tool replace the auditor?

No. A GRC tool such as CISO Assistant or eramba Community tracks controls, risks, owners and evidence, but it does not issue a SOC 2 report. Only an independent CPA firm can examine your controls and issue an opinion. The Journal of Accountancy reported in February 2026 that many SOC tool vendors are not CPA firms and cannot attest that controls are effective, and that compliance promises made in weeks or hours do not match how examinations work. Use a GRC tool to organize the work and keep the register current, and treat the auditor's testing as the only attestation. Ask any vendor exactly what their product records and what it does not claim.

Which edition limits in open-source tools matter for SOC 2?

Edition limits matter when a control depends on a feature held back from the free version. Check each tool's license and feature matrix before you design controls around it, because the answer changes by product and by release. Examples to verify include whether audit logs of administrative actions are retained in the free edition, whether access certification workflows are available without a paid tier, whether reporting exports are included, and whether support terms affect patching. The eramba Community license forbids modification and redistribution, which is a different limit from an AGPL open-core model. Confirm each limit in writing with the vendor and record it in your system description.

What should we ask a partner before signing a fixed-scope engagement?

Ask for a written scope that names each system, each tool, each control and each deliverable, plus the acceptance criteria for each one. A partner prepares systems, controls and evidence, but it does not issue audit reports or certifications, so ask who on the auditor side will receive that evidence. Also ask who owns the controls after handover, how backups and upgrades are handled, what happens if the auditor requests additional evidence, and which work is excluded from the fixed price. DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure and most engagements are fixed-scope, so the written scope is the basis for the quote. Ask for the same scope to be reviewed by your auditor before work starts.

How DeployOpen deploys these tools and prepares evidence

DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For SOC 2 tooling, that means the identity, logging, access review, secrets, scanning and change control tools are configured to produce the records an independent CPA firm will sample, while your organization keeps ownership of its controls.

How we scope

Engagements are fixed-scope, with the tools, environments and Trust Services Criteria areas agreed in writing before work starts.
The written scope names which controls each tool covers, which evidence it produces and which controls remain manual.
Licenses and edition limits are confirmed for each tool, including which audit logs and features need a paid edition.
We agree who owns each control, so the scope separates implementation work from decisions your management must make.

How we build

Single sign-on, MFA enforcement, log collection, access certification, secrets management and vulnerability scanning are deployed in your environment.
Alerting rules, protected branch settings and scan schedules are configured and tested against the control descriptions you provide.
Integrations are built so each tool's output is stored where your auditor can request it, with retention settings documented.
Test runs confirm that a sample event, review or scan produces the expected record before the environment is handed over.

How we hand over

You receive configuration documentation, an evidence map linking each tool output to the criterion it supports, and operating runbooks.
Owners, review frequencies and escalation steps are written down so the controls can run without the implementation team.
Known gaps, such as logs missing in a free edition or manual steps a tool does not automate, are listed in the handover.
Evidence collection routines are demonstrated to your staff so the first observation period starts with working records.

How we support

Ongoing support, upgrades, backups and continuous testing are available as retainers after handover.
Upgrade planning covers license changes and version updates, so an evidence gap does not appear unnoticed mid-period.
Support does not replace the auditor: DeployOpen prepares systems and evidence, while the independent CPA firm performs the examination and issues the report.
Before your audit, confirm with your CPA firm which evidence formats and sample periods it expects from each tool.