What Dify audit logging covers for compliance evidence
The Dify Enterprise audit log gives you attributable records of who did what to apps and access, but it is only one part of the evidence a regulated team needs. It records the operator account, the API key, the IP address, the operation type and the resource affected for actions such as creating API keys, exporting DSL, publishing apps and changing web app access. Those fields cover three requirement areas that auditors commonly ask about: operator attribution (which person or key acted), change traceability (what was exported, published or altered) and access change history (who changed who can reach a web app). Before you rely on it, confirm the exact event list and field names in the current Dify Enterprise audit log documentation for your version, because the set of recorded operations is what determines which questions you can answer from the log alone.
The audit log does not, by itself, meet several requirements that a compliance review may raise. Online queries cover only the last 90 days, so anything older must be retrieved from the CSV archive, and you need to confirm how long archives are kept and who can access them. The log is not described as tamper-resistant in the supplied material, so you should ask the vendor how records are protected from alteration and plan for write-once storage or a SIEM copy if your control requires it. The log also does not define review procedures: someone must own a recurring review of exports, publishes and access changes. Finally, it says nothing about model-provider records, such as which provider accounts were configured, under what contract and with which data terms. Those belong in your own vendor and change registers, and the audit log should be treated as one input to them.
Mapping audit requirements to Dify capabilities and configuration
This table maps common audit log requirements to what the Dify Enterprise audit log records, the configuration or process you need around it, and who usually owns that work. Read each row as a question to answer with your auditor before you rely on the platform for evidence. The main takeaway is that the platform records operations, but retention periods, exports and review routines are decisions your organization must document.
| Requirement area | Dify Enterprise capability | Configuration or process needed | Owner |
|---|---|---|---|
| Operator attribution | Records the operator account and IP address for logged actions | Confirm each reviewer account maps to one named person through SSO, and forbid shared operator accounts | Identity or IAM team |
| API key creation | Records creation of API keys with operator, API key and IP address | Define who may create service API keys, and review logged key creation against an approved request | Platform owner and security |
| DSL export | Records DSL export events, which show who took app configuration out of the workspace | Set a rule for when export is allowed, and store exported YAML under the same access controls as the source app | App owner and data protection lead |
| App publishing | Records publishing of apps, tying a release to an operator and time | Tie publishing to your change process, so each logged publish matches an approved change ticket | Change management and app owners |
| Web app access changes | Records changes to web app access settings | Review access level changes regularly, and confirm external user access is approved by a named sponsor | Access governance team |
| Retention and online window | Online queries cover the last 90 days; older logs are archived and downloadable as CSV | Confirm with your auditor which retention period applies, then export and store CSV archives and SIEM copies to meet it | Compliance lead with platform and storage owners |
| SIEM feed for long-term retention | CSV exports can be loaded into a log platform for longer retention and correlation | Plan a scheduled export, record the export procedure, and test that a sampled event can be found after import | Security operations |
Which operations the Dify Enterprise audit log records
The Dify Enterprise audit log records who did what, from where, and to which resource. Each entry captures the operator account, the API key used, the IP address, the operation type and the resource affected. The covered actions named in the Dify Enterprise audit log documentation include creating API keys, exporting DSL, publishing apps and changing web app access. Attribution depends on these fields together: the operator account identifies the person, the IP address and API key show the channel used (console session or programmatic call), and the operation type and resource show what changed. A record that names an app but not the account behind a publish, or an API key but no operator, leaves a gap in the answer an auditor will ask for.
Before you rely on the log for a control, test which events appear in your version. Create a test API key, export a DSL file, publish a test app, change a web app access setting, then search the log for each action and confirm every field is populated as you expect. Record the Dify version, the test steps and the results, because this becomes the evidence that the log covers the operations your control describes. Ask your Dify Enterprise contact to confirm the full event list for your release, since coverage is version-specific and the documentation alone does not settle it for your environment.
The log is not a complete data record. DSL exports, as described in the Dify app management documentation, include app configuration, workflow nodes, model parameters, prompts and knowledge base connections, but exclude third-party API keys, knowledge base content and usage logs. An audit entry showing that an export happened does not show what was in the exported file or what data the app processed. Plan separate evidence for knowledge base contents, usage and model provider records, and for any control that depends on the content of an exported artifact.
Evidence the audit log produces and how to keep it
The audit log is only one of several records a self-hosted Dify deployment produces. Each item below proves a different thing, lives in a different place and needs a different reviewer, so retention and access rules have to cover all of them.
Audit log entries
Each entry records the operator account, API key, IP address, operation type and resource for actions such as creating API keys, exporting DSL, publishing apps and changing web app access. Online queries reach back 90 days, so anything older must already be archived. Check that your team can filter entries by resource and operator before an auditor asks. Security operations and the compliance lead should review access changes weekly.
CSV archives of older records
Records older than the online window are archived and downloadable as CSV. The archive is the evidence that survives past 90 days, so it needs a named owner, a storage location outside the Dify host and a checksum or hash recorded at download. Confirm with your vendor how often archives are generated and whether the CSV format keeps all the fields you need. Compliance should sample archives each quarter to confirm they open and contain the expected date range.
SIEM copies of audit events
Forwarding audit events to your SIEM gives you a second copy that Dify administrators cannot edit and a retention period set by your security team, not by the application. Confirm whether your Enterprise release supports direct forwarding or whether you must export and ingest files. Map the fields to your detection rules, such as bulk DSL exports or web app access granted to external domains. The SOC should own the detection rules and the compliance lead should own the retention schedule.
DSL export records
A DSL export is a YAML file of app configuration, workflow nodes, model parameters, prompts and knowledge base connections. It excludes third-party API keys, knowledge base content and usage logs, so the export itself is not a full copy of the app's data. Record who exported which app and where the file went, because an exported prompt can leave your control. Treat exported DSL files as confidential, keep them in a restricted repository and have the app owner review them before release.
App version history
Version history shows which published state of an app was live at a given time, which is what links a logged publish event to the prompts and workflow that answered users. Keep the version identifiers in your change records so an auditor can match a publish entry to a specific configuration. Confirm how versions are retained after an app is deleted. The app owner and the change approver should both sign off on publishes that affect regulated use cases.
SSO-linked access records
Access records tie a person to a workspace or web app through the identity provider, and Dify Enterprise separates SSO scopes for workspace access and web app access. Export the group memberships at each review date so you can show who could reach an app at that time, not only who did. Check that a leaver in your identity provider also loses Dify access, and keep the review results with the audit log archive. Access reviewers should compare the identity provider export against the audit log's access change entries.
Configuring audit logging and SIEM export in sequence
This sequence turns the Dify Enterprise audit log into retained, attributable evidence by confirming the edition, identity attribution and retention rules before exports begin. It ends with a documented review cadence that an auditor can sample.
Confirm the Enterprise edition and version
The platform owner confirms that the deployment runs Dify Enterprise, because the audit log is an Enterprise feature and the Community edition does not provide it. Record the exact Enterprise version and the Dify version in your change records, and check it against the audit log documentation for that version. Output: a dated record of edition and version, stored with the deployment documentation. Ask your vendor to confirm in writing which audit log fields and operations exist in your version, since the operation list may vary between releases.
Confirm SSO identity attribution
The identity owner checks that every administrator and builder signs in through the SSO configuration, so that audit entries tie operations to a named person instead of a shared account. Test with two or three accounts, including one that belongs to an admin group, and confirm the operator field in the log matches the individual. Shared service accounts and generic API keys should be listed separately, because the log records API keys as well as operators. Output: a short attribution test record showing that each test action maps to a single identifiable person.
Define the retention period with the auditor
The compliance lead agrees the retention period with the internal or external auditor before the first export, since the platform's online window is only 90 days and the retention obligation comes from your framework, contracts or internal policy, not from Dify. Document which operations must be kept, who may request records, and how long archives must remain readable. Confirm with the auditor that CSV files are an acceptable evidence format. Output: a signed retention decision that names the period, the record types and the system of record for archives.
Schedule CSV exports ahead of the window
The platform team sets a recurring export job or calendar task so that records are downloaded as CSV before they age past the 90-day online query window. Older logs are archived and downloadable as CSV, so the export routine must run on a fixed cadence that leaves margin before the window closes. Store each file in write-once or access-restricted storage with a checksum and the export date in the file name. Output: an export log showing the date range covered by each file, with no gaps between consecutive ranges.
Forward exports to the SIEM
The security engineer loads the CSV files into the SIEM or log platform through an approved ingestion path, such as a scheduled upload from the storage bucket or a parser that maps the CSV columns to the SIEM schema. Map the operator, API key, IP address, operation type and resource fields so that they are searchable. Apply the retention policy inside the SIEM as well, and restrict who can delete events. Output: a SIEM index or dataset holding the exported records, with a parser that has been checked against a sample file. Confirm with your SIEM vendor how it handles the CSV format and retention limits.
Test that a sample operation appears end to end
The QA owner performs known test actions, such as exporting a DSL file, publishing an app, creating an API key and changing web app access, then follows each one through the Dify audit log, the CSV export and the SIEM search. Each action should show the correct operator, time, IP address, operation type and resource. Repeat the test after any upgrade or change to the export job. Output: a test record listing each action, the matched entries in each system and any gaps, signed by the reviewer. Label any mismatch as a finding and fix it before accepting the pipeline.
Document the review cadence
The compliance lead writes down who reviews audit records, how often, which events trigger a review (such as API key creation, DSL export or access changes to published web apps) and how findings are escalated and closed. Assign a named owner for the export job and a backup owner. Keep the review minutes and export logs together so an auditor can sample a month of activity and trace it back to the source. Output: an approved audit log procedure with a review schedule, a responsibility matrix and a sample set of completed review records.
Questions buyers ask before hiring help with Dify audit logs
Do I need the Dify Enterprise edition to get audit logs?
Yes, the audit log described here is part of Dify Enterprise, and the community edition does not provide it. The Dify pricing page lists the self-hosted Community edition as free and limited to a single workspace, while the self-hosted Enterprise edition is custom priced and adds SSO, multiple workspaces, advanced security, a commercial license and professional support. Confirm with Dify which Enterprise version and license terms fit your organization, since the price is quoted rather than published. If you run only Community edition, your own logging of API and infrastructure events becomes the evidence source, and that design needs its own review.
What does audit logging setup cost and what drives the price?
DeployOpen does not publish prices, and the cost follows from a written scope. The main components are Dify Enterprise licensing from Dify, the infrastructure that hosts it, and the implementation work: confirming which operations must be captured, configuring retention and exports, connecting a SIEM or log store, and documenting the procedure for pulling archived CSV files. Costs rise with the number of workspaces, the SIEM integration complexity, the number of teams who need access to exports, and how much evidence mapping the compliance team requires. Ask for a quote that separates one-time build work from any recurring support or retainer.
How long does audit log setup take?
Duration depends on the environment and the evidence requirements, so ask for a timeline in the written scope rather than relying on a general figure. The work usually depends on the state of the Dify deployment, whether Enterprise is already licensed and running, how many workspaces need coverage, whether a SIEM is already in place, and how quickly the compliance owner can agree on retention periods. Access approvals for the SIEM and the storage location for CSV archives often set the pace more than the Dify configuration itself.
What does our team need to provide before the work starts?
Plan to provide access and decisions, not just a kickoff meeting. You will need to confirm which Dify environments and workspaces are in scope, the Enterprise license and version, the target SIEM or log platform and its ingestion requirements, the retention period your policy requires, and the named owners who will receive exports. You also need a test account or change window to generate sample events such as exporting DSL, publishing an app and changing web app access, so the captured records can be checked end to end.
Can we set up Dify audit logging in-house?
Yes, if your team has Dify administration skills, Kubernetes or Docker operations experience, and someone who can own SIEM ingestion and retention. The Dify audit log is documented, and the online window of 90 days plus CSV archives for older records are the main constraints to design around. In-house teams usually struggle with the recurring parts: scheduled exports before the 90-day window closes, consistent field mapping into the SIEM, and proving to an auditor that the procedure ran as written. Document those tasks regardless of who builds the setup.
Does DeployOpen certify that our Dify deployment is compliant?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. A well-configured audit log helps your auditor sample records and trace operations, but the assessment outcome depends on the auditor's review of your full control set, including access reviews, change management and vendor records.
How do we check that the logs capture what we need?
Test the chain end to end before you rely on it. Trigger a set of known operations, such as creating an API key, exporting a DSL file, publishing an app and changing web app access, then confirm each record shows the operator account, API key where applicable, IP address, operation type and resource. Next, confirm the same events arrive in the SIEM with correct timestamps and fields, and that a CSV export of an archived record can be retrieved and read. Ask your implementation partner to document this test as part of the handover.
What the audit log does not cover
The Dify Enterprise audit log is one piece of compliance evidence, not the whole of it. The gaps below sit between what the log records and what an auditor or regulator will ask you to show, so confirm each one with your auditor and with Dify before you rely on the log.
Online retention ends at 90 days
Online queries cover only the last 90 days, and older records are archived and downloadable as CSV. Any review that reaches further back depends on your export process working on time. Ask Dify how archived records are stored, how long the archive itself is kept, and whether the CSV export is complete for the period you need. Then check that your export schedule runs before the 90-day window closes.
Retention and deletion ownership
The log records what happened, but it does not decide how long evidence must be kept. Your organization must set the retention period for audit logs, conversation logs and exports, and name who approves deletion. Confirm with your auditor and legal or records team which retention period applies to each record type, and confirm how Dify's own cleanup settings interact with that period.
Tamper evidence of exports
A CSV export is a copy, and a copy can be edited. Nothing in the export itself proves it matches the source records at the time it was taken. Decide how exports are hashed or signed, where they are written, and who can write to that location. Ask your auditor which integrity controls they expect for exported evidence, and ask Dify whether the export carries any integrity metadata.
Review and alerting processes
Recording an operation is different from someone reviewing it. The audit log does not define which events need follow-up, such as API key creation, DSL exports or web app access changes, or how quickly they are checked. Define review cadence, alert rules in your SIEM, and the owner of each alert. Confirm with your auditor how often reviews must be evidenced and what sample they will request.
Model provider and knowledge base records
The audit log covers operator actions, not the content or configuration behind them. DSL exports do not include third-party API keys, knowledge base content or usage logs, so model provider records and document history must come from elsewhere. Map which systems hold provider contracts, key rotation records and knowledge base change history, and confirm with Dify which of these it can produce for an auditor.
Independent audit and certification
DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Only an independent auditor or certification body can conclude that your controls meet a framework. Agree the evidence set with your auditor early, confirm which audit log fields and exports they will accept, and treat any statement about compliance status as their decision, not the platform's.
Preparing audit log evidence for an external assessment
An assessor rarely asks for the whole audit log. They pick a sample of operations, such as a DSL export, a publish, or a change to a web app's access, and ask you to show the matching entry, the identity behind it and the record of any export you handed over. Build the evidence package the same way. For each sampled operation, record the operator account, the API key where one was used, the IP address, the operation type and the resource, then confirm that the SSO identity linked to that operator account is the person you expect. Keep the export records alongside, with the date range, who ran the export and where the CSV was stored, so the assessor can see that the copy they reviewed matches the source. Your Dify Enterprise audit log only holds online queries for the last 90 days, so any sample that reaches further back depends on the archived CSV exports you produced at the time.
DeployOpen prepares systems, controls and evidence for these assessments. We do not issue audit reports, attestations or certifications. An independent auditor or certification body decides whether the evidence is sufficient, and they decide what it has to prove. Before you collect anything, hold an early conversation with your auditor about which framework applies to the system and how long audit records must be retained. A retention period set by a framework can be longer than the 90-day online window, and some assessors want logs held outside the Dify host. Agree on the sample size, the date range and the format they will accept, then configure exports and SIEM retention to meet that agreement rather than retrofitting it after the fieldwork begins.
Confirm three things with your auditor and your own records owner before the sampling period starts: which operations are in scope, which identity source is authoritative for operator accounts, and who signs off each exported file. Test the package once internally by picking a few operations at random and tracing each one from the Dify entry to the SSO identity to the stored export. Gaps found during that dry run are cheap to fix. Gaps found by the assessor are not.
How DeployOpen scopes and delivers Dify audit logging work
DeployOpen plans Dify audit logging as part of the self-hosted platform, inside your own infrastructure. We start from the operations your compliance evidence must cover, then agree the retention path, SIEM feed and handover in writing before build work begins.
How we scope
- Confirm which Dify edition and license your deployment uses before assuming audit log access.
- Map the recorded operations your reviewers need, such as API key creation, DSL export and web app access changes.
- Agree in writing how exports are pulled, stored and retained beyond the 90-day online query window.
How we build
- Configure the audit log pipeline and export schedule in your environment, with access restricted to named reviewers.
- Connect exported CSV records to your SIEM and test that operator, IP address and resource fields arrive intact.
- Run test operations such as an app publish and an access change, then confirm each appears in the log and the feed.
How we hand over
- Document the export procedure, retention location, owners and the steps for retrieving archived records.
- Provide a runbook for reviewing logs, handling gaps and recording evidence for your compliance team.
- Walk through the handover with your operators so the log pipeline can be run without DeployOpen present.
How we support
- Offer ongoing support as a retainer to check exports, SIEM ingestion and retention after each Dify upgrade.
- Review audit log behavior when Dify releases change, since minor releases arrive roughly monthly.
- Confirm with your auditor or certification body which log fields and retention periods they will sample.
