Dify for ISO/IEC 42001 AI management systems

How Dify fits an ISO/IEC 42001 AI management system

A regulated team building LLM workflows and agents inside an AI management system needs to know which requirements a self-hosted Dify can help evidence and which it cannot. Dify supplies technical records: the app inventory, version history of apps and releases, model provider configuration, and, on Enterprise, audit logs. It does not supply the policy, impact assessment, risk decisions or governance that ISO/IEC 42001 also expects from the organization. ISO/IEC 42001:2023 sets requirements for establishing, implementing, maintaining and improving the management system, so most of the management system sits with your organization, not with the platform.

ISO does not certify organizations. External certification bodies do, and they assess against the standard using rules set in ISO/IEC 42006:2025. Annex A controls are not all mandatory: your statement of applability, required by clause 6.1.3, lists the controls you need and justifies including or excluding each one. Build that statement first, then map Dify records to the controls it keeps, such as the AI system inventory, change control over prompts and workflows, and third-party provider records. Confirm with your certification body how it expects these records to be sampled before you decide the evidence format.

Some of this evidence depends on the Enterprise edition. The Community edition is limited to a single workspace, and the audit log and SSO features that show who changed or accessed an AI system across an organization are listed under Enterprise on the Dify pricing page, so confirm what your required records need before choosing an edition. Plan retention for exported logs and configuration snapshots outside the platform, because the evidence an auditor samples must still exist when the assessment happens.

Mapping ISO/IEC 42001 requirements to Dify capabilities and configuration

This table maps ISO/IEC 42001 clauses 4 to 10 and the relevant Annex A control areas to the Dify capability, the configuration it needs and the evidence an assessor can sample. Rows marked for confirmation depend on your Dify edition, version or environment, so verify them before you rely on them. Use the table as a starting point for your statement of applicability, not as proof that any control is met.

Requirement area	Dify capability and configuration	Evidence an auditor can sample
Clause 4 context and scope (A.2 policies, A.3 internal organization)	Define the AI system boundary per Dify workspace. Community edition is limited to one workspace, so plan a workspace per use case or confirm Enterprise multi-workspace needs.	Written scope statement, workspace list, named owners for each app
Clause 5 leadership and roles	Assign workspace roles and map them to who approves changes to prompts, workflows and model choices. Confirm role granularity in your edition.	Role assignment records, approval records for app changes
Clause 6.1.3 statement of applicability	Record which Annex A controls apply to each Dify app and why others are excluded. Dify does not decide applicability for you.	Statement of applicability with justifications, reviewed on a set cycle
Clause 7 support and resources (A.4 resources)	Document the Dify version, Docker Compose or Kubernetes layout, and the model providers and vector store in use. Confirm sizing against the official resource requirements.	Architecture record, version inventory, resource requirement checklist
A.6 life cycle: change control and version history	Export each app as YAML DSL before and after changes, and record the Dify release applied. Releases arrive roughly monthly, so set a review schedule per release.	DSL export files in version control, release notes reviewed, upgrade change tickets
A.6 life cycle: upgrades and backups	Take a backup before every upgrade, check `.env.example` for new variables, and follow the target version's upgrade guide. Exports do not include knowledge base content or usage logs, so back those up separately.	Pre-upgrade backup records, post-upgrade variable diff, test results
A.7 data: secrets and encryption	Set `SECRET_KEY` before first start and protect it, since changing it logs out all users. Confirm where workspace encryption keys are stored for your environment.	Secret storage records, key custody procedure, access list for the key
A.7 data: outbound request control	Route outbound requests through the SSRF proxy so internal and private ranges are blocked. Confirm that the proxy settings match your network policy.	Environment configuration file, network test results
A.8 information for interested parties and A.9 use: audit trail	Enterprise audit logs record operations such as DSL export and web app access changes. Online query covers a limited window, so export older records to your retention system. Confirm the audit log scope for your Enterprise license.	Audit log exports, retention schedule, SIEM ingestion records
A.9 use: human oversight	Use the Human Input node in workflows where a person must review or approve output. Confirm how review decisions are logged in your Dify version.	Workflow diagrams showing review steps, sample review records
A.10 third parties: model provider records	Keep a register of each model provider, the model used, the account owner and the data terms. Dify does not hold your contracts, so the register comes from your procurement records.	Provider register, contract references, credential rotation records
A.10 third parties: access and SSO	Enterprise SSO supports OpenID Connect, SAML and OAuth2, with separate scopes for workspace and web app access. Confirm the identity provider and scope mapping in your tenant.	Identity provider configuration export, access review records

What evidence a self-hosted Dify gives an auditor to sample

An auditor testing an AI management system will ask for records, not descriptions. The cards below cover the artifacts a self-hosted Dify can produce, what each one proves, and where its gaps sit. Keep each artifact in a repository or evidence store you control, dated and versioned, so the sample can be pulled without relying on the live platform.

App inventory from DSL exports

Export each app as a YAML DSL file to build a dated inventory of AI systems in scope. The export carries app configuration, workflow nodes, model parameters, prompts and knowledge base connections, which lets an auditor compare what is running against what was approved. Exports omit third-party API keys, knowledge base content and usage logs, so the inventory must be paired with separate records for those. Confirm that every production app appears in the inventory.

Version history and change records

Dify keeps app versions, but a version history is only audit evidence if each change links to a request, a reviewer and a test result. Store each exported DSL file in Git with the approval reference in the commit message, so the diff shows exactly which prompt, model or tool changed. Check that a sampled app can be traced from its current version back to an approved change.

Enterprise audit log exports

On Dify Enterprise, the audit log records operations such as app changes and access updates. Export the log on a fixed schedule and store the files outside the platform, because the retention window for online queries is limited. Auditors often sample a change and ask who made it, when and whether it was approved, so confirm that exports carry those fields for your edition before you rely on them.

SSO and role assignments

Access records show who could change or operate each AI system. Keep exports of identity provider group membership, the Dify roles mapped to those groups, and the workspace and web app access scopes. Enterprise SSO supports OpenID Connect, SAML and OAuth2, so the identity provider is the system of record. Review the export each quarter and record the reviewer's sign-off, since that sign-off is the evidence.

Model provider configuration records

Each model provider an app calls is a supplier relationship that the management system must control. Record which providers are configured, which models and endpoints each app uses, who approved them and the contract or data terms on file. Dify stores provider credentials inside the platform, so keep the approval record and rotation history separately. Use the same list to confirm that no app calls a provider missing from the register.

Upgrade records tied to release notes

Each Dify upgrade should leave a record: the target version, the release notes reviewed, the pre-upgrade backup reference, the new variables checked against the example environment file and the test outcome. Dify minor releases arrive roughly monthly, so an upgrade log shows whether the system stayed supported and changed under control. Store the backup checksum with the record so an auditor can see the rollback point existed.

Where Dify human review nodes help with oversight, and where they do not

The Human Input node gives a workflow a defined point where a named person must act before the run continues, and the decision can be recorded as part of that run. This supports the human oversight and use controls you document for ISO/IEC 42001, including the use area (A.9) and the life cycle area (A.6), because you can show that a person was in the loop for specific outputs. Before you rely on it, confirm in your version exactly what the node stores: who acted, when, what content they saw, what they submitted, and whether the record lands in the run log, the conversation record or only the workflow state. Also confirm how long those records stay online, how they are exported and whether your retention period can be met without an additional export step.

The node does not decide who should review, what the reviewer checks, whether the reviewer has the competence for the task or whether the use case is acceptable. Those remain your responsibility under your AI policy, your roles and resources (A.4) and your impact assessment. For the impact assessment, use the guidance in ISO/IEC 42005:2025, published on 28 May 2025, to document affected people, foreseeable misuse and the conditions under which a human must review. A recorded approval shows that a review step happened. It does not show that the review was sound, so the evidence you keep should include the criteria and the reviewer's qualifications alongside the recorded decision.

What Dify does not cover for ISO/IEC 42001

Dify produces some of the records an ISO/IEC 42001 management system draws on, but most of the management system sits with your organization. The cards below list the work a self-hosted Dify cannot do for you, and the edition questions to settle before you plan evidence collection.

AI policy and objectives

Clause 5 and the policy controls in Annex A (A.2) require a documented AI policy and measurable objectives approved by leadership. Dify has no policy record, so the policy text, its owner and review dates live in your document system. Check that every Dify app traces back to a stated objective and that the policy names which uses are permitted.

Roles and responsibilities

Dify workspace roles show who can edit an app, but they do not show who owns the AI system, who approves changes, or who answers for its outcomes. Document named owners for each app, the reviewers who approve publishing, and the operators who run the platform. Confirm that the roles in Dify match that written allocation.

AI impact assessments and risk decisions

Impact assessment controls in Annex A (A.5) ask you to assess effects on individuals, groups and society before and during use. Dify provides no assessment template or risk register. Related guidance in ISO/IEC 42005:2025 and ISO/IEC 23894:2023 can shape the method, and your assessments must cover each high-impact app.

Data quality, provenance and suppliers

Dify stores knowledge base content but does not record where data came from, whether it is fit for purpose, or how it was labeled. Decisions on data quality and provenance (Annex A, A.7) and agreements with model providers and customers (A.10) sit in contracts and data registers you maintain. Dify's export and records only show the configuration that points to these sources.

Statement of applicability, audits and nonconformities

Clause 6.1.3 requires a statement of applicability that justifies including or excluding each Annex A control. Internal audit, management review and nonconformity handling under the management system clauses are also process work, not platform features. Dify logs can support the sampling, but the decisions and corrective actions must be written and tracked by your team.

Edition limits and certification

Community edition is limited to a single workspace and does not include SSO, multiple workspaces or audit logs, so most audit evidence depends on the Enterprise edition, which is custom priced and quoted from written scope. ISO does not certify organizations; accredited certification bodies do. Ask any quote to state which Dify edition and records it assumes.

Configuring Dify so the evidence is usable

This sequence sets up a self-hosted Dify so that the records an ISO/IEC 42001 auditor would sample, such as the app inventory, access, model provider records, oversight points and version history, exist, are current and can be exported on a schedule.

Define the AI system inventory and workspace structure
Before building anything, the AI management system owner lists each AI system that will run in Dify, including its purpose, owner, users, data sources and the model providers it depends on. Map each entry to a Dify workspace and app, so that one app corresponds to one inventoried system. On Community, a single workspace is the only option, so the inventory must record that boundary explicitly. Done means every app in Dify has a matching inventory row with an accountable owner.
Set identity and roles through SSO
Connect the identity provider before onboarding real users. On Dify Enterprise, the SSO documentation lists OpenID Connect, SAML and OAuth2, with identity providers such as Microsoft Entra ID, Okta and GitHub, and separate scopes for workspace access and web app access. Assign roles according to the inventory so that access decisions trace to a group in your directory. Confirm with the Enterprise team which provisioning and role options your edition includes. Done means a test user from each role can sign in and sees only the workspaces and apps assigned to them.
Configure secrets and SECRET_KEY handling
Generate the SECRET_KEY value once, store it in your approved secrets manager and inject it into the environment file at deployment. The environment reference says it signs session cookies and JWTs and encrypts OAuth credentials, and changing it after deployment logs out all users, so record the change date and the approver if rotation is ever planned. Decide whether workspace encryption keys stay local or move to Azure Key Vault. Done means the key source, custody owner and rotation procedure are written down and the value is absent from version control.
Route outbound requests through the SSRF proxy
Keep the SSRF proxy in the Docker Compose stack and point outbound settings, including tools and external API calls, through the SSRF_PROXY configuration. According to the environment reference, this proxy blocks internal and private IP ranges, which supports the claim that model and tool traffic follows an approved path. Record the egress rules you expect, then test one blocked internal address and one approved external endpoint. Done means the test results are saved as evidence against the network control.
Record model providers and their configuration
For each provider connected in Dify, record the provider name, the model names enabled, the contract or internal approval reference, the credential owner and the workspace where it is used. Store the credentials in Dify's model provider settings, not in prompts or app exports, because DSL exports do not include third-party API keys. Note when a provider or model is added or removed, since that becomes a change record. Done means the provider register matches what the Dify console shows for each workspace.
Set up Human Input nodes where oversight applies
For each app whose outputs affect people or decisions, place a Human Input node at the step where a reviewer must approve, edit or reject the output, as your impact assessment and Annex A controls require. Document the reviewer role, the escalation path and the conditions that trigger review. Run a test conversation and confirm that the review step pauses the workflow and records the reviewer's action. Done means each in-scope app has a tested review point and a written oversight rule linked to its inventory row.
Set a backup and upgrade routine
Schedule backups of the database, file storage and configuration before every upgrade, as the Docker Compose documentation recommends. For each planned upgrade, read the release notes for the target version on the Dify releases page, follow the upgrade guide, and compare your .env file against .env.example for new variables. Minor releases arrive roughly monthly, so the routine should name who reviews each release. Done means every upgrade has a change record listing the version, the release notes reviewed, the backup reference and the post-upgrade test result.
Schedule periodic evidence exports into the management system
Define a recurring export set for the AI management system: the app inventory and DSL exports, role and access lists, model provider register, change records, backup logs and, on Enterprise, audit log exports. Assign an owner and a calendar for each export, and store the output in your document control system with a version date. Tell the internal audit lead which exports the auditor can sample. Done means a dated evidence pack exists and matches the inventory, and the owner has confirmed each item is complete.

Questions buyers ask before hiring help with Dify and ISO/IEC 42001

Can a self-hosted Dify make our organization ISO/IEC 42001 certified?

No. Dify is a software platform, and it cannot make an organization certified. ISO does not certify organizations; external certification bodies do, and accreditation of those bodies is voluntary. The certification body assesses your whole AI management system, including policies, risk and impact assessments, roles and records. What a self-hosted Dify can do is produce much of the technical evidence that assessment samples, such as an app inventory, version history, model provider records and, on the Enterprise edition, audit logs. DeployOpen prepares systems, controls and evidence for compliance assessments, but does not issue audit reports, attestations or certifications. Ask any partner who claims otherwise to show the certification body involved.

What drives the effort of an ISO/IEC 42001 Dify project?

Effort depends mostly on four things: the number of AI systems in scope, the number of Dify workspaces, how identity is integrated, and how mature your existing management system already is. Each Dify app, knowledge base and model provider connection adds records to maintain. Multiple workspaces multiply access reviews and configuration checks. SSO and role mapping add identity work. If you already run an ISO/IEC 27001 management system, much of the document control, internal audit and management review structure can be reused, because ISO/IEC 42001 uses the same harmonized structure of clauses 4 to 10. Confirm these inputs with your team before requesting a quote.

Can our own team do this without an outside partner?

Yes, for many of the records and configuration tasks, provided you have people with the time and skills to keep them current. Your engineers can set up workspace naming, export DSL files, record model provider details and collect version history. The parts that need an internal owner are the policy set, the AI impact assessment, the risk treatment decisions and the statement of applicability required by clause 6.1.3, because those decisions reflect your business and must be accountable to leadership. A partner typically adds value in configuration review, evidence design and sampling rehearsal, but your organization still owns the management system.

What do we need to provide before a partner starts the work?

A partner needs a clear picture of your environment and your decisions. Prepare the following before the first working session:

An inventory of AI use cases you already know about, with business owners and data types.
Access to a staging Dify instance and a list of workspaces, roles and identity provider details.
The model providers and self-hosted model endpoints in use, plus who holds the credentials.
Your existing ISO/IEC 27001 or other management system documents, if any.
A named internal owner with authority to approve policies and risk decisions.

Without these, the partner will spend the engagement discovering scope rather than building evidence.

What drives the cost, and what should a written quote include?

Cost is driven by scope and by which Dify edition you run. The self-hosted Community edition is free and limited to a single workspace, while the self-hosted Enterprise edition is custom priced according to the Dify pricing page and adds SSO, multiple workspaces, advanced security, a commercial license and professional support. Licensing is therefore a recurring cost to confirm with Dify, separate from any services fee. Services are one-time for the initial design and evidence build, and recurring if you want ongoing evidence refresh. Ask any partner for a fixed-scope quote that lists the AI systems in scope, workspaces, identity integrations, deliverables, acceptance criteria, timeline, and what is excluded, such as policy drafting or the certification audit itself.

How often does our Dify evidence need refreshing with monthly releases?

Evidence should be refreshed with every version change that touches your AI systems, and at a fixed review cycle set by your management system. Dify minor releases arrive roughly monthly, for example 1.16.0 on July 17, 2026 and 1.17.0 on August 25, 2026, so waiting for an annual review would leave version history stale. Treat each upgrade as a change event: record the target version, take a backup before upgrading as the Docker Compose docs advise, check .env.example for new variables, and update the app and model records. Decide with your team whether you will upgrade every release or on a set cadence, and document that choice in your change control procedure.

Which parts of the evidence should an auditor sample from Dify?

Auditors usually sample records rather than read configuration screens, so prepare exports they can trace. Useful samples include the app inventory with owners and purpose, DSL exports showing prompts, workflow nodes and model parameters, version history for changed apps, and records of model provider connections. Exports do not include third-party API keys, knowledge base content or usage logs, so keep those under separate control. On the Enterprise edition, audit log exports can support change and access records. Confirm with your certification body which samples they expect before you finalize the design.

Does a self-hosted Dify with SSO meet the access control requirements?

SSO helps, but it does not settle access control on its own. The Dify Enterprise SSO documentation lists OpenID Connect, SAML and OAuth2, with providers such as Microsoft Entra ID and Okta, and separate scopes for workspace access and web app access. You still need documented role assignments, periodic access reviews and a joiner and leaver process that your management system defines. Community edition login options are more limited, so confirm which identity controls your edition supports before writing them into your statement of applicability.

Community or Enterprise: which edition supports the audit trail

The Community edition is free to self-host, runs anywhere Docker runs and is limited to a single workspace. It gives you the app objects an auditor is likely to sample, but it does not provide the Enterprise audit logs, SSO scopes or multiple workspaces, so most of the record-keeping layer is yours to design and run.

App inventory: Apps, their prompts, workflow nodes and knowledge base links are visible in the single workspace. Keep a register outside Dify that maps each app to an owner, business purpose, intended users and the impact assessment that covers it, following the app management documentation.
Version history: Export each app as a YAML DSL file whenever it changes. Exports cover configuration, workflow nodes, model parameters, prompts and knowledge base connections, but not third-party API keys, knowledge base content or usage logs, so archive those separately.
Model provider records: Provider keys stay out of DSL exports. Record each provider, model, version, contract and data terms in your own register, and keep key rotation under your secrets process.
Run logs: Conversation and workflow logs are kept in the platform, but how long they persist before cleanup is a configuration decision. Schedule exports into a log store you control so that samples survive cleanup.
Human review evidence: Record review decisions for workflows with human steps in your own ticketing system, linked to the app version and the DSL export it ran on.

Before committing, confirm which console views and exports your target version supports and how long each log type is retained.

How DeployOpen scopes Dify compliance evidence work

DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Dify under an ISO/IEC 42001 AI management system, we start by agreeing which AI systems, controls and evidence the written scope covers, then build and document the platform so your team and your certification body can sample it.

How we scope

Inventory the Dify workspaces, apps and AI use cases that fall inside the AI management system boundary.
Agree in writing which Annex A controls apply and which are excluded, with the reasons your statement of applicability will record.
Confirm whether your Dify edition supports the audit log, SSO and workspace separation the evidence plan depends on.
Identify which model providers, knowledge bases and human review points each in-scope app relies on.

How we build

Deploy Dify in your cloud accounts, data centers or air-gapped network, with the components and secrets handling agreed up front.
Configure version history, change records and app export routines so each app's configuration can be traced over time.
Set up human review steps, provider records and access roles that match the controls named in the written scope.
Test the configured evidence paths, including whether records can be exported and retrieved for a sampled app.

How we hand over

Deliver an evidence map linking each in-scope control to the Dify setting, log or record that supports it.
Document the runbook for backups, upgrades, model provider changes and periodic app inventory reviews.
Provide a written record of what the platform supports and what your organization still owns, such as policy and management review.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped in writing.
Review each Dify minor release against the documented evidence paths before your team applies it.
Ask any certification body or auditor to confirm the evidence requirements, since DeployOpen prepares evidence but does not issue audit reports or certifications.