Which open-source tools produce ISO 42001 evidence, and what they cannot do
When a customer or regulator asks for ISO/IEC 42001 evidence for your AI systems, the honest answer is that several open-source tools can produce operational evidence for specific Annex A controls, but no tool makes your organization compliant or issues a certificate. Your organization owns its controls and their evidence. An implementation partner such as DeployOpen can install, configure and document the tools inside your own infrastructure and help prepare the evidence, but only an accredited certification body certifies an AI management system. Start by asking which controls your statement of applicability includes, because ISO/IEC 42001 does not require every Annex A control. Clause 6.1.3 requires you to justify each inclusion and exclusion, so the statement of applicability decides which evidence you need and which tools are worth deploying.
Tool choice follows from the controls in scope. Tracing and evaluation platforms such as Langfuse, which is released under the MIT license, can record model calls, token usage, inputs and outputs, and produce scores that support verification and monitoring of AI behavior. Vulnerability scanners such as garak, licensed under Apache-2.0, generate a JSONL report of every probe and a hit log of attempts that found a weakness, which is useful test evidence. Governance tracking is a separate need. CISO Assistant, licensed under AGPL-3.0-only, keeps risk registers, applied controls, evidence and remediation plans, and its library includes an ISO/IEC 42001:2023 framework. Confirm each license against the repository's LICENSE file before you commit, and check the edition limits: Langfuse's self-hosted audit logs, project-level RBAC roles, data retention policies, server-side data masking, protected prompt labels and SCIM need an enterprise license key.
Maintenance status matters as much as features. LLM Guard, which screens prompts and responses for injection, secrets and sensitive data, was archived on July 9, 2026, so it receives no security fixes and should not be the only control in a new design. Before you rely on any tool, check its repository activity, release history and open security issues, and record that check as evidence. Tools produce records but cannot decide whether a risk is acceptable, whether an impact assessment is adequate or whether management review took place. Those decisions, and the documented records of them, stay with your people and your management system.
Tracing, evaluation, scanning, screening and GRC tools by evidence type
Langfuse is the tool in this group. It is MIT-licensed and records what your AI application did at runtime. Each trace captures the operations in a request, including LLM calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. Evaluation features score production traces and run experiments on datasets, using LLM-as-a-judge evaluators and human annotation queues. Evidence from these features is most useful for monitoring, performance and event logging, and for showing how a system was verified before release.
- Runtime records: traces show what happened on individual requests, which supports operational logging and incident reconstruction.
- Evaluation history: dataset experiments and scored traces document how a system was checked against defined expectations.
- Deployment gates: evaluations can be wired into CI/CD to block a release when scores fall below a threshold you set.
- Enterprise features: audit logs, project-level RBAC, data retention policies, server-side data masking, protected prompt labels and SCIM need an enterprise license key in self-hosted deployments.
- Human review: annotation queues record who reviewed outputs, but you still need to write the review criteria and reviewer competence rules.
Before relying on it for audit evidence, confirm with the project which features your self-hosted edition includes and how long your deployment retains traces.
garak is an Apache-2.0 licensed scanner that probes language models for weaknesses, including hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. It writes a JSONL report of every attempt and evaluation, plus a hit log listing attempts that found a vulnerability. That pair of outputs is useful evidence for verification and validation, because it shows what was tested, when, against which model configuration, and what failed. It does not decide whether a result is acceptable for your use case.
- Full attempt log: the JSONL report records every probe attempt and evaluation, which supports reproducibility.
- Hit log: a separate list of successful attacks gives you the input for risk treatment decisions.
- Scope limits: the probes cover the threat categories the project implements, so untested risks remain untested.
- Decisions you own: you must define the acceptance thresholds, record which findings were fixed or accepted, and document the residual risk.
- Re-runs: keep the configuration, model version and date with each run so you can compare results after changes.
Confirm the current probe catalog and the report format in the project README before you design your test plan, since both can change between releases.
LLM Guard is an MIT-licensed toolkit with input scanners, such as PromptInjection, Anonymize, Secrets and Toxicity, and output scanners, such as Sensitive, Deanonymize, MaliciousURLs and FactualConsistency. Used in a request path, it screens prompts before they reach a model and responses before they reach a user. The project was archived on July 9, 2026, so it no longer receives development or security fixes. That status changes how you can use it for evidence, and it should drive a decision before you deploy it.
- Archived status: the project and its Hugging Face models receive no security fixes, so any vulnerability found after archival stays open unless you patch it yourself.
- Screening logs: if you enable logging, scanner results can show what was blocked or flagged, which supports operational monitoring.
- Policy ownership: you decide which scanners run, their thresholds, and what happens when a scanner flags content.
- Replacement planning: record which control depends on the screening, and document how you would replace or compensate for the tool.
- Custom scanners: any scanner you write needs its own testing and change records.
Before using the tool, check the archive notice in the repository and decide whether to accept a maintained replacement or a documented compensating control.
CISO Assistant is an AGPL-3.0-only governance, risk and compliance platform. Its open framework library includes an ISO/IEC 42001:2023 framework and a mapping between ISO/IEC 42001:2023 and the Secure Controls Framework. The platform keeps risk assessments and registers, applied controls, evidence, remediation action plans and a third-party risk module. It is the place where your statement of applicability, risk register and evidence index can live in one system, rather than in scattered documents.
- Framework library: load the ISO/IEC 42001:2023 framework to structure your Annex A review, then confirm each entry against the current standard.
- Risk and actions: risk assessments, registers and action plans record how identified AI risks are treated and who owns them.
- Evidence linking: attach artifacts, such as trace exports, scan reports and approval records, to the applied controls they support.
- Third-party module: track AI suppliers and their assessment status for Annex A.10 relationships.
- Your decisions: the statement of applicability, justifications for exclusions and the choice to use the bundled mapping are yours to make and approve.
Before you rely on the bundled library or mapping, check the library files in the repository against the published standard and have your certification body confirm the mapping you intend to use.
Which self-hosted features need an enterprise license
Langfuse's core tracing and evaluation features are available under the MIT license, but several controls an assessor will ask about sit behind an enterprise license key. Before you choose a deployment design, check which of these controls your evidence depends on and confirm the current terms with the vendor.
Self-hosted audit logs
Audit logs record who changed projects, prompts, users and settings, and when. Auditors reviewing access and change management under ISO 42001 expect this kind of trail for AI tooling. If your evidence plan depends on it, treat the enterprise license as a prerequisite and ask the vendor which log events are covered and how long they are retained on your side.
Project-level RBAC roles
Role-based access at project level limits which engineers, reviewers and auditors can view traces, datasets and evaluation results. This supports access control evidence for AI systems that process sensitive inputs. Without it, you may need to separate projects by deployment instead, which changes how you document scope and ownership.
Data retention policies
Retention settings define how long traces containing prompts, outputs and token metadata are kept. Your retention rule should match the data classification in your AI policy and your data governance controls. Confirm whether retention can be enforced per project and whether deletions are logged, because an assessor will test both the setting and its operation.
Server-side data masking
Server-side masking removes sensitive values from traces before they are stored, which reduces the chance that personal data or secrets end up in your evidence archive. Client-side redaction in your application is a separate control. Test masking with realistic but synthetic inputs and record the results, since masking gaps are a common finding in data quality reviews.
Protected prompt labels
Protected labels restrict who can promote a prompt version to production. This supports change control over the prompts that shape system behavior, a point assessors often raise under life cycle and use controls. Document the approval step that precedes promotion, and confirm with the vendor that protection applies to the API as well as the interface.
SCIM user provisioning
SCIM connects Langfuse to your identity provider so that user accounts are created, changed and removed automatically. Joiner, mover and leaver evidence then comes from your directory rather than manual admin lists. Confirm how deprovisioning propagates to API keys and sessions, since removing a user from the directory should also cut off access.
Why LLM Guard's archived status changes the screening plan
LLM Guard is MIT licensed and offers input scanners such as PromptInjection, Anonymize, Secrets and Toxicity, plus output scanners such as Sensitive, Deanonymize, MaliciousURLs and FactualConsistency, but the project was archived on July 9, 2026. It is no longer developed or maintained, and its Hugging Face models are archived with it, so no security fixes will arrive. Any screening plan that names LLM Guard as the control for prompt and output filtering must be reviewed before the evidence is relied on, because the component now carries the risk of an unpatched dependency in the path of every model request.
For ISO/IEC 42001 evidence, the problem is defensibility rather than function. An assessor who asks how a control that screens prompts or responses is kept effective will expect a current, supported component, a record of who monitors it, and a way to respond to new bypasses. A control that depends on an archived project with no fixes is hard to defend, even if its scan logs look complete. Confirm the current status yourself by checking the project's repository and the Hugging Face model pages, and record the date you checked. Do not assume a fork or a community patch is maintained without seeing its commit history and release notes.
Treat this as a risk decision. Record the archived status as a risk in your register, assess which AI systems depend on the scanners, and document a treatment, whether that is replacing the scanners, adding compensating controls such as additional monitoring or red team testing, or accepting the residual risk with a named owner and review date. Assess alternative screening products against the same input and output coverage you need, and keep the comparison in the decision record. Your statement of applicability and management review minutes should show that the change was considered and approved.
How tool output becomes ISO 42001 audit evidence
The sequence turns tool output into dated, traceable records that an auditor can sample against the statement of applicability, with each finding tied to a control, an owner and a management review decision. The organization owns every step, and an independent certification body, not the tooling, decides whether the evidence meets the standard.
Define in-scope AI systems and controls
Start by listing each AI system the organization develops, provides or uses, along with its intended purpose and owner. Map those systems to the Annex A controls that the statement of applicability (clause 6.1.3) includes, and record a justification for each exclusion. Done means every in-scope system has a named owner and a control list that a reviewer can read without the tooling. Confirm the scope with your certification body before you build the evidence trail.
Instrument systems for traces and scores
Engineering teams add tracing to the AI application so each request produces a record of LLM calls, retrieval steps, tool executions, inputs, outputs, token usage and metadata. Langfuse, which is MIT licensed, can hold these traces and evaluation scores on infrastructure you run. Confirm which features you need, because audit logs, role-based access control, retention policies and data masking on a self-hosted instance require an enterprise license key. The check is a sample trace per in-scope system that an assessor can open and follow end to end.
Run garak probes on a fixed schedule
The security or AI engineering team runs garak, an Apache-2.0 scanner, against each in-scope model or application on a schedule the organization sets and documents. Probes cover hallucination, data leakage, prompt injection, misinformation, toxicity and jailbreaks. Each run writes a JSONL report of every attempt and evaluation, plus a hit log of attempts that found a vulnerability. Store the reports with the run date, model version and configuration so the results can be reproduced.
Screen prompts and outputs at runtime
Where the design calls for runtime screening, the engineering team places input and output scanners in front of and behind the model. LLM Guard, an MIT licensed project, provides scanners such as PromptInjection and Secrets for inputs, and Sensitive and MaliciousURLs for outputs. LLM Guard was archived on July 9, 2026, so it receives no security fixes, and the organization must decide whether to accept that risk, replace the component or maintain it internally. Evidence is the scanner configuration and the logged block or flag events.
Log results as evidence against controls
The GRC team records each report, trace sample and screening log in CISO Assistant (AGPL-3.0-only) as evidence and links it to the applied control it supports. CISO Assistant's library includes an ISO/IEC 42001:2023 framework, so the control list from step one can be loaded there. The output is an evidence record with a date, a source file or link and a control reference. Check that every in-scope control has at least one linked item before the next review.
Open remediation actions for findings
When a probe finds a vulnerability or a trace shows a failed evaluation, the owner opens a risk entry in the CISO Assistant risk register and a remediation action with an accountable person. The risk is assessed against the organization's own criteria, and the treatment decision (mitigate, accept, transfer or avoid) is recorded. The output is a closed loop: the finding, the risk record, the action and the retest evidence all link to the same control.
Report to management review
Management reviews the risk register, evaluation trends, open remediation actions and any scanner or component issues, such as an archived dependency, at planned intervals. The review records decisions, resource needs and changes to the AI policy or statement of applicability. The minutes and the updated register are the evidence that management review operates, and they feed the next internal audit cycle. Independent auditors test these records, and the organization should ask its certification body which sample sizes and periods it expects to see.
What must be in place before the tools produce usable evidence
Open-source tracing, scanning and GRC tools only produce evidence an assessor can rely on when the organization has already decided what it is governing. The six items below connect the tools to the ISO/IEC 42001 requirements they support, and each one lists a check you can run before the first assessment.
Defined AI system inventory
Every trace, scan and screening log has to point back to a named AI system, so the inventory is the key that links tool output to an accountable owner. Check that each system has a name, a version, a purpose, the teams that build or use it, and the data it touches. Ask whether a system that is not on the list can still send traces to the tracing platform. If it can, the inventory is incomplete, and the evidence will not cover everything in scope.
Statement of applicability
Clause 6.1.3 requires a statement of applicability that lists the Annex A controls you need and justifies including or excluding each one. The tools only need to produce evidence for controls that are in that statement, so it sets the scope of your evidence plan. Check that every control marked as included has a named tool, manual process or both that produces its evidence, and that each exclusion has a written reason an assessor can review.
Named control owners
A tool can record that a scan ran, but it cannot decide whether the result is acceptable or who must act on it. Each Annex A control in scope needs a named owner who is accountable for its design, its evidence and its remediation. Check that every owner appears in the GRC tool with a role, a deputy and a review date, and that owners can explain what their control requires without reading the tool's dashboard.
Retention rules for prompts and traces
Traces contain inputs, outputs and metadata, which can include personal data, so retention is both an evidence question and a privacy question. Decide how long traces, evaluation scores, scan reports and screening logs are kept, and who may delete them. Confirm the retention setting in your tracing platform, and check whether the features you need, such as data retention policies and server-side data masking, are part of the free edition or require an enterprise license key.
Access control on the tools
The tracing platform, scanners and GRC tool hold sensitive data about models, prompts and risks, so they must meet the same access rules as the systems they describe. Check that administrator access is limited, that single sign-on and multi-factor authentication are enforced where the tool supports them, and that role-based access separates people who view evidence from people who change it. Confirm which of these controls need a paid edition before you rely on them.
Decision on who reviews results
Scan findings, evaluation scores and screening alerts only count as evidence once someone reviews them and records a decision. Name the reviewer for each tool, set the review cadence, and define the escalation path when a result crosses a threshold, such as a failed evaluation that should block a release. Check that the reviewer has the authority to stop a deployment and that the review outcome is recorded in the GRC tool, not only in the scanner's output.
What the tools cost and what the organization still pays for
This table separates the cost components of running open-source ISO 42001 evidence tools into one-time and recurring items, names who is paid for each, and lists what drives it up or down. Use it to structure a quote request, since no prices are published here and DeployOpen quotes follow a written scope.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Tool licenses | Nothing for core open-source use (Langfuse MIT, garak Apache-2.0, CISO Assistant AGPL-3.0-only); enterprise features need a commercial license key | Recurring if enterprise features are needed | Which self-hosted features you require, such as audit logs, RBAC, retention and SCIM; confirm license terms with the vendor |
| Hosting and infrastructure | Your cloud account, data center or air-gapped network, plus any managed hosting you contract | Setup one-time, running costs recurring | Trace volume, evaluation runs, storage retention periods and high availability requirements |
| Implementation partner work | External partner, under a written fixed scope where agreed | One-time, with optional retainers for upgrades and testing | Number of tools deployed, integration with existing GRC and identity systems, and how much hardening and documentation is in scope |
| Internal staff time | Your own engineers, risk owners and compliance staff | Recurring | Frequency of reviews, number of AI systems in scope, and how many evidence sources must be reconciled by hand |
| Security testing and scanning runs | Internal team or external testers, depending on who runs garak or other scans | Recurring per test cycle | Number of models under test, probe coverage chosen, and how often scans repeat after model or prompt changes |
| Upgrades and maintenance | Your team, or a partner under a retainer | Recurring | Maintenance status of each tool; LLM Guard was archived on July 9, 2026 and receives no security fixes, so plan a replacement |
| Independent certification body fees | The accredited certification body you hire, not the tool vendor or DeployOpen | One-time certification plus recurring surveillance and recertification | Scope of the AI management system, number of sites and systems, and the body's own fee schedule; request it in writing |
| Quote request checklist | Ask each vendor and partner for a written scope, deliverables and assumptions | Set before work starts | Ask for named tools, versions, hosting model, support hours, what the organization must own, and exclusions |
Questions buyers ask about open-source ISO 42001 tooling
Can open-source tools alone get us ISO 42001 certified?
No. Tools produce evidence, but certification depends on your AI management system, your documented decisions and an independent certification body that audits them. ISO does not certify organizations, and external certification bodies do. Your statement of applicability must justify which Annex A controls you include or exclude, and no tool writes that justification for you. Tracing, evaluation and scanning tools can show that a control operates, such as logs of model behavior or results of security tests, but the auditor will also ask who owns the AI policy, how risks were assessed and how management reviewed the results. Ask any certification body which records it expects to sample before you choose a tool stack, because the required evidence should drive the tooling rather than the reverse.
Do we need an enterprise license for open-source AI governance tools?
It depends on the tool and the features you need. Langfuse is MIT-licensed and its core tracing and evaluation features are available in the open-source edition, but its self-hosted audit logs, project-level RBAC roles, data retention policies, server-side data masking, protected prompt labels and SCIM need an enterprise license key. These are controls an assessor may look for, especially access control and audit logging. Garak is Apache-2.0 and CISO Assistant is AGPL-3.0-only, so review what the AGPL obligations mean for your deployment before you modify or distribute it. Before you commit, map each control you plan to evidence to the license tier that provides the feature, and confirm current terms in the LICENSE file of each repository.
Is LLM Guard safe to use after it was archived?
Treat it as a risk you must document, not as a safe default. LLM Guard was archived on July 9, 2026, so its project and Hugging Face models are no longer developed or maintained and receive no security fixes. Its MIT license still permits you to run and fork it, but that does not give you ongoing patches. If you already run it, record the archive date in your risk register, assess the exposure of the input and output scanners it provides, and decide whether to keep it, replace it or maintain a fork under your own security process. Any replacement needs its own evaluation before it appears in your evidence.
What does open-source AI governance tooling need from our staff?
It needs engineers who can run and secure the platforms, and governance owners who can interpret the output. Platform engineers operate the tracing, evaluation and scanning services inside your own cloud accounts or data centers, handle upgrades, backups, access control and network placement, and watch for maintenance changes such as archival notices. Security engineers configure scanner probes, triage garak hit logs and decide what counts as a finding. Governance or compliance staff own the AI policy, the statement of applicability and the risk decisions, and they must be able to explain what each record proves. Plan for these roles before you deploy, because a tool without an owner produces logs nobody reviews.
Can DeployOpen issue the ISO 42001 evidence or the certificate?
DeployOpen can plan, implement, configure, harden, document and support the self-hosted open-source platforms that produce evidence, and it can prepare systems and records for an assessment. It does not issue audit reports, attestations or certificates. Those come only from an independent certification body. Evidence your organization owns, such as the AI policy, risk decisions and management review minutes, stays with your team, and the tool outputs are yours to retain. Scope, deliverables and timelines are agreed in writing before work starts, and the quote follows from that written scope. Keep the certification body independent from the partner that built your systems so the audit remains credible.
How do we choose between a GRC tool and a spreadsheet for ISO 42001?
Choose a GRC tool when you need linked risk registers, controls, evidence and remediation actions with many owners, and a spreadsheet when the scope is small and the reviewers are few. CISO Assistant (AGPL-3.0-only) keeps risk assessments and risk registers, applied controls, evidence, remediation action plans and a third-party risk module, and its library includes an ISO/IEC 42001:2023 framework and a mapping to the Secure Controls Framework. Confirm that the library's mapping and framework content match your current ISO/IEC 42001:2023 copy before relying on it. Spreadsheets are cheap to start but struggle with version history, evidence links and access control, which assessors often ask about. Whichever you choose, the statement of applicability and management review records must still be authored by your organization.
How much effort does running LLM tracing and evaluation take?
The effort is driven by how many AI systems you run, how much traffic they carry and how many controls you evidence through the tool. Langfuse traces capture LLM calls, retrieval steps, tool executions, timing, inputs, outputs, token usage and metadata, and its evaluators can run on production traces or datasets. Costs fall into three groups: infrastructure you run in your own environment, engineering time to instrument applications and set up evaluators, and the review time that turns scores into governance decisions. Ask any implementation partner for a written scope that lists the systems, environments and evidence records covered, since that scope determines the quote.
Who owns the tools, the evidence and the certificate
The organization owns its AI management system, its controls and every decision that follows from the evidence. Open-source tools generate traces, scan results and screening logs, but they do not decide whether a risk is acceptable or whether a control is operating as intended. Those judgments belong to named people inside the organization who can explain them to an assessor.
- Control ownership: Name an owner for each control in the statement of applicability, including the tracing, evaluation and screening controls that the tools support.
- Result review: Assign people to read garak reports, evaluation scores and blocked-prompt logs on a set schedule and record what they found.
- Risk treatment decisions: Decide which findings are accepted, mitigated or transferred, and record the reasoning in the risk register.
- Management review: Bring tool results and open findings to leadership so the review is documented as an input to the management system.
- Tool selection and licensing: Confirm license terms and edition limits, and decide whether features that need an enterprise license are required.
Before you rely on any tool output, confirm with your own team which findings the organization has actually reviewed and acted on.
An implementation partner such as DeployOpen installs, configures, hardens, backs up and documents the open-source tools inside your own infrastructure, then prepares the evidence that the organization reviews. The partner works from a written scope and does not own the controls, make risk decisions or sign any assurance statement. Its role ends at preparing systems and evidence for the assessment.
- Installation and configuration: Deploy the tracing, evaluation, scanning and governance platforms in your cloud account, data center or air-gapped network.
- Hardening and access: Set up role-based access, secrets handling and network controls, and confirm which features are available under your license.
- Backup and upgrades: Define backup, restore and upgrade procedures so that logs and records survive maintenance.
- Documentation and evidence packs: Write runbooks, map tool outputs to control IDs and prepare evidence for the organization to review.
- Testing support: Run scheduled scans or red team exercises when the scope includes them, and hand results to the organization for triage.
Ask any partner to state in writing which tasks it performs and which stay with your staff.
An independent auditor or accredited certification body assesses whether the management system meets ISO/IEC 42001 and issues any report or certificate. ISO does not certify organizations, and the certification body must be independent of the organization and of any firm that helped prepare for the audit. Neither the tool vendor nor the implementation partner can issue the certificate.
- Assessment: The auditor samples evidence, interviews owners and checks that controls operate as described in the statement of applicability.
- Independence: Confirm that the certification body is accredited and has no conflict with the consultant or partner who prepared your evidence.
- Certification decision: Only the certification body decides whether to issue the certificate and under what scope.
- Surveillance and recertification: Ongoing audits are performed by the same independent body, not by the partner.
- Scope of the certificate: Confirm with the certification body whether the certificate covers your tools, services and AI systems in the scope you defined.
Before you engage a certification body, confirm its accreditation status with the accreditation body in its country and ask how it handles independence from preparation work.
How DeployOpen scopes and prepares ISO 42001 evidence tooling
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source tools inside your own infrastructure, so the tracing, testing, screening and GRC records that support ISO 42001 evidence sit where your organization controls them. We prepare systems and evidence for your assessment, while your organization owns its controls and an independent certification body issues any certificate.
How we scope
- We agree a written scope listing which tools, environments and AI systems are covered before work starts.
- Scope names the Annex A controls the evidence supports, mapped to your statement of applicability.
- Engagements are fixed-scope, with deliverables and timelines confirmed in writing before any build begins.
How we build
- We deploy tracing, evaluation, scanning and GRC tooling in your cloud accounts, data centers or air-gapped networks.
- We check each tool's license and edition limits, such as enterprise-only features, against the controls it must evidence.
- We configure access controls, data retention and logging so the records you produce hold up to assessor questions.
How we hand over
- You receive documentation of configurations, evidence collection steps and the owner of each evidence source.
- We set up the ISO 42001 framework library in your GRC platform, with your own risk register and applied controls.
- Handover includes a walkthrough so your staff can run evidence collection and explain the records to an auditor.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We track maintenance status of open-source components, such as archived projects, and recommend replacements in writing.
- Your organization should confirm current license terms and maintenance status for each tool with its maintainers before relying on it.
