Dify for GDPR: personal data in prompts, logs and knowledge bases

Mapping GDPR requirements to Dify capabilities and configuration

This table compares each GDPR obligation relevant to personal data in Dify with the platform capabilities the docs describe and the settings to confirm in your environment. Dify supplies some technical controls, but none of the rows is satisfied by Dify alone, since the controller and processor remain responsible for the overall compliance position. Read each row as a starting point for your own assessment.

Where personal data lands: prompts, logs, files, chunks and traces

Personal data in a Dify deployment does not sit in one place. It is spread across the metadata database, file storage, the vector store and the observability layer, and each store has its own location and retention behavior. Map these five locations before you set a legal basis, a retention period or an erasure procedure.

Setting retention and erasure for each data store

How end-user identifiers link records to a person

Handling an erasure request across a Dify deployment

This sequence turns a GDPR erasure request into a traceable set of deletions across Dify's databases, file storage, vector index and traces, with each location confirmed and the outcome recorded. It works without assuming Dify exposes a single erasure function, which the team must verify for its version.

1. Log the request and verify the data subject

   The controller's privacy or legal owner records the request, its date and the identifiers the requester supplied, such as an email address or the end-user identifier used with the app. Confirm the requester's identity through a method proportionate to the data held before any search begins. Done when the request has a reference number and a named owner, and the identifiers to search for are written down.

2. Map where the person's data sits

   Before touching anything, the operator lists every place the person's data may exist in this deployment: the metadata database (conversation and message records, end-user records, app logs), file storage (uploaded files), the vector store (knowledge chunks derived from those files), any tracing or observability backend connected to the apps, and external model provider logs. Confirm with your own configuration which of these are active, because the Dify environment reference lets operators choose the database, storage and vector store. Done when the map names each store and the query or method used to search it.

3. Locate records in the metadata database

   A database administrator queries the metadata database for the identifiers from step one, covering conversations, messages, uploaded file records and any end-user identifiers passed by your application. Record each matching row by table and key, and note any records linked to shared knowledge bases that other people also use. Confirm the query scope against a test copy first if your team has not run it before. Done when the set of matching primary keys is saved with the request.

4. Remove matching files and knowledge chunks

   Using the records from the previous step, the operator removes the uploaded source files from the configured file storage and deletes the derived chunks from the vector store, since a chunk can carry personal data even after the source file is gone. Check whether the Dify version you run offers a document or segment deletion path in the console or API, and confirm that path removes both the stored file and its index entries. Done when a repeat search of the file store and vector store for the identifiers returns no matches.

5. Delete conversation records and confirm traces

   Delete the matching conversation and message records in the metadata database, or use the application's supported deletion path if your version provides one, and check the tracing backend and any logs shipped from the containers for the same identifiers. Note that prompt text may also sit in logs held by a model provider under its own retention terms, which you must request separately. Done when the database query returns no matches and each trace or log store has a recorded result, including stores where nothing was found.

6. Address backups and exports

   Identify every backup set and exported DSL or data file that may contain the person's records. Backups are usually not edited in place, so the team should document the retention period for each backup, confirm whether the erased data will be restored later, and set controls so any restore re-applies the erasure. Confirm the backup mechanics with your own backup tooling and your legal team. Done when a written note states which backups hold the data, when they expire, and how a restore will be handled.

7. Confirm the erasure request in the record

   Write a closing record that lists each store searched, the query used, the deletions made, the stores where nothing was found, the backup treatment, and the date the work finished. Also note the Dify version and any gaps, such as traces held outside the deployment. Confirm with the requester where required, and keep the record with your processing documentation. Done when the record is signed off by the privacy owner and filed under the request reference.

Keeping processing in EU infrastructure without losing the model

What do buyers ask about Dify and GDPR before hiring help?

Evidence to keep for a GDPR file and how to keep it

A GDPR file for a Dify deployment is a set of records that shows what personal data each app touches, how long it is kept, who can reach it and how requests were handled. The cards below cover the records to keep, where each one comes from in Dify, and what to check before relying on it. An auditor or supervisory authority decides whether the file is sufficient.

Configuration sequence for a GDPR-ready Dify deployment

This sequence turns a self-hosted Dify installation into one where personal data has a known location, a defined lifetime, a controlled path to any model provider and evidence that each setting was chosen on purpose. It is meant for the platform team and the privacy lead working together before any production users log in.

1. Inventory data flows and applications

   The platform owner and the privacy lead list every Dify app, knowledge base, file upload and workflow that could receive personal data, and record which model providers, plugins and external tools each one calls. Map each flow to the stores where it lands: the metadata database, file storage, the vector store, conversation logs and any traces. This step is done when every flow has a named owner, a stated purpose and a documented list of storage locations that the team can point to during a data subject request.

2. Choose region and storage locations

   Infrastructure and security leads decide where the metadata database, file storage and vector store will run, then confirm that every component sits inside the EU or in infrastructure your organization controls. Dify supports PostgreSQL, MySQL or OceanBase for metadata, several object storage providers for files, and Weaviate or other vector stores, so each choice should be recorded with its hosting location. Confirm with your cloud or data center provider where backups and replicas are held, because copies outside the EEA can count as transfers under the EDPB guidance. Done when the storage map has a location and an owner for each store.

3. Set SECRET_KEY and encryption keys

   The security engineer generates a strong SECRET_KEY before first start, stores it in the organization's secrets manager and sets it in the environment file used by the deployment. The same person confirms how workspace encryption keys are held, either locally or in Azure Key Vault where that fits your estate, and records who can rotate them. Because changing SECRET_KEY after deployment logs out all users, the team should not treat it as a routine rotation item. Done when the key is stored outside the repository, access is restricted to named operators, and a restore test confirms encrypted credentials can still be read.

4. Route outbound calls through SSRF_PROXY

   The platform engineer configures SSRF_PROXY settings so that outbound requests from Dify, including tool calls and document fetches, pass through the proxy that blocks internal and private IP ranges. The engineer then tests an outbound request to a private address from a workflow and confirms it is refused, and checks that approved model endpoints remain reachable. Record the allowed destinations in the change log. Done when the test evidence shows blocked internal calls and an approved list of external hosts that the privacy lead has reviewed.

5. Select model providers by location

   The privacy lead and the application owner choose each model provider and embedding service by where it processes prompts, retrieved chunks and outputs, and by whether it stores them. For a cloud provider, the team should confirm the processing region, retention terms and whether any third-country access is possible, which may require a transfer assessment under Chapter V. For self-hosted or on-premises inference, the team records the host location and the network path from Dify. Done when each provider in the Dify configuration has a signed-off location record that matches the data flows from the first step.

6. Configure retention and cleanup

   The operator reviews the retention settings for conversation logs, uploaded files and knowledge chunks, then sets periods that match the purpose and lawful basis documented in step one. Dify's own cleanup behavior and any scheduled jobs should be tested on a non-production copy so the team knows what is deleted, when, and from which stores. Backups need their own retention rule, because a deleted record may persist in older snapshots. Done when a test record is removed from logs, files and the vector index according to the documented schedule, and the backup retention period is written down.

7. Define end-user identifiers

   The application owner decides how end users are identified when they call a Dify app through the service API or a web app. Use an opaque, pseudonymous identifier issued by your own identity system rather than names, email addresses or national identifiers, and document how that identifier maps back to a person for erasure requests. Confirm which identifiers appear in conversation records and traces. Done when a sample conversation shows only the agreed identifier and the mapping procedure has been tested by the team that handles requests.

8. Document exports, version pinning and upgrades

   The platform owner pins the Dify version and image digests in the deployment, records the release used and keeps the DSL exports of each app in version control. The DSL export documentation notes that exports exclude third-party API keys, knowledge base content and usage logs, so the team must keep those records in their own systems. Set an upgrade routine that follows the release cadence, reads the upgrade guide for each target version, checks the .env.example file for new variables and takes a backup before every upgrade. Done when the pinned version, the export archive and a tested backup restore are recorded together and the upgrade calendar names an owner.