Review n8n data flows and retention

What the software provides. Software can provide capabilities and contractual documents that support an appropriate implementation. The organisation still needs to determine why personal information is processed and which requirements apply. The European Commission explains the GDPR principles, including purpose limitation, minimisation, limited retention and appropriate security.

A testable question. Ask a testable question: “May we process these contact details through these systems to handle this service request, and which controls are needed?” That is more useful than a generic product verdict. A technically similar workflow handling applications for employment or health information can require a different assessment.

People concerned. Identify the people whose data is involved. Business contact details can still be personal information; B2B processing is not automatically exempt. The EDPB small-business fundamentals explain applicability and the need for an appropriate lawful basis. Sources and product documentation were checked on 26 September 2026.

From intake to deletion. Start at intake and follow every path to deletion. Record the mailbox or form, n8n instance, temporary storage, destination and notification channel. Add error logs, backups, test copies and external support. These secondary routes are frequently missing from a simple architecture diagram.

Fields per transfer. For each transfer, identify the actual fields. A CRM task might need a contact ID, request category and owner, rather than the entire email history. If a language model only classifies a request, justify why it needs names or complete attachments.

Manual work. Include manual work. During an incident, a support person may inspect execution data or send a screenshot to a supplier. Define those activities deliberately instead of improvising them under pressure.

Transformed information. The map should also show where information is transformed. A summary can still contain personal information, and a reference may still identify somebody when combined with another system. Treat those outputs according to their actual content and use.

One representative case. For one representative case, trace where personal information originates, which systems receive it, which copies are created and when those copies are removed. Include error messages, approval notifications and support cases. A diagram showing only three product logos often misses these secondary paths.

Synthetic example. In a synthetic recruitment process, an error notification might attach an entire CV to a team channel. The document repository could have correct permissions while the notification creates additional recipients. A better design reports a case reference and links to controlled storage where that is sufficient for handling the issue. The lawfulness of the underlying process still requires its own assessment.

Secondary paths. Record purpose, recipients and retention for each secondary path. This concrete inventory supports the responsible privacy reviewers and makes technical corrections verifiable without implying blanket compliance.

Initial design. A service company wants to categorise enquiries and assign them in a CRM. Its initial design sends the subject, message, signature, all attachments and previous correspondence to an AI service. Every step also retains the full content, while errors are copied into a general team channel.

Narrower design. A narrower design separates responsibilities. Each enquiry receives an internal reference. A deterministic preprocessing step removes unnecessary material. Classification receives only the content required for its purpose. The CRM step writes the reference, category and owner. Error alerts contain a case ID and failure class; authorised staff open details through the intended system.

The table lists five kinds of information in the example workflow with the question to ask before transfer and a possible limitation.

This is neither a legal approval nor a tested customer implementation. It illustrates how to reduce the technical data scope before legal review. Assess whether the remaining information is still personal; replacing a name column does not automatically anonymise free text.

Controller and processor. Determine which organisation decides the purposes and means, and which processes information on its behalf. The Commission's guidance on controllers and processors explains those roles and processor agreements. Do not automatically assign the same role to every supplier.

n8n Cloud and self-hosting. n8n describes a data-processing agreement for its cloud service and identifies subprocessors. Self-hosting changes the operating structure and technical responsibility. Review the current n8n privacy documentation alongside the actual contracts.

Supplier record. Create one supplier record per connected service: activity, data categories, account holder, processing locations, further recipients, deletion and support. An agreement with the workflow platform does not automatically cover an OCR or model API you connect separately. Assess an implementation partner according to the access it actually receives.

Technical changes. Keep the contractual record aligned with technical changes. Adding an extra notification service or diagnostic tool can create another recipient even when the main business workflow still appears unchanged.

Server location. Server location answers only part of the architecture question. The workflow may still transmit information to other services. Administration, support and other contractual processing also need consideration. Examine actual recipients and data flows rather than only the main server address.

Germany, Austria and Switzerland. GDPR is central for Germany and Austria, with possible additional sector-specific requirements. For Swiss organisations, assess applicable Swiss law and any additional GDPR connection separately. The FDPIC guidance on cross-border disclosure explains the Swiss assessment of disclosure abroad.

Scope of the review. One DACH architecture can be technically feasible without every legal conclusion being identical. State which legal entity, groups of individuals and countries the review covers. A pattern examined for an Austrian company should not be silently treated as approval for another organisation.

Missing facts. If a supplier's location or access arrangements are unclear, record the missing fact. Do not substitute the supplier's headquarters or marketing description for evidence about the selected service.

What is stored. n8n can retain execution inputs and outputs. This helps diagnosis but creates additional information stores. Decide, per workflow, what is genuinely needed for troubleshooting and when it should be removed.

Pruning and exceptions. The official execution-data guide explains storage and pruning options. Check exceptions: waiting cases, specially annotated executions and external storage may behave differently from ordinary completed runs. Setting a number in configuration does not prove that every relevant copy disappears on that schedule.

Deletion test. Test deletion with a uniquely marked synthetic record. Then inspect execution history, intermediate storage, exported files and intended diagnostic routes. For backups, consider the documented retention and recovery procedure. Define how information previously deleted from normal operation is handled after restoration.

Retention period. Avoid adopting an arbitrary retention period from a tutorial. The period should reflect the stated purpose, operational needs and applicable requirements. Document who approves it and how its operation is checked.

Three kinds of access. Distinguish access to the editor, execution information and connected applications. A person who can change one workflow should not automatically see every department's data or make arbitrary external requests. Available roles depend on edition and plan.

Separate connections. Use separate connections for distinct purposes where the target supports them. A read-only report does not need broad deletion rights. A test workflow should not have the same powers as production message delivery. Limit supplier personnel to the agreed scope as well.

Personal accounts. Shared operation needs identifiable accounts and absence cover. A single shared administrator account makes attribution and selective offboarding difficult. Record access reviews and verify revocation when a person leaves.

Effective capability. Examine effective capability, not just whether a secret is visible. Somebody able to modify a workflow using a privileged credential may be able to perform actions with that authority without ever reading the underlying key.

Two different things. A model call configured in your workflow is different from an AI assistance feature in the platform. They can involve different information, settings and terms. n8n's privacy documentation also describes diagnostics and AI usage settings; review the sections relevant to your deployment and version.

Diagnostics. Disabling diagnostics does not prevent an HTTP Request node you configured from sending data elsewhere. Conversely, a locally running workflow does not prove that no supporting service is contacted. Examine the actual configuration and record deliberate choices.

Model providers. For model providers, assess inputs, retention, additional uses and contracted protections. Do not rely on a general statement about a model brand. A personal chat account and a contractually configured API service can have different terms.

Free text and comments. Review free-text fields and code comments too. Staff may inadvertently place sensitive examples inside configurations used for troubleshooting. Synthetic examples can provide the necessary context without copying genuine customer material.

Individual requests. Define how authorised staff locate data for a verified request and assess the required action. An automatic deletion webhook without identity and authority checks can itself cause harm. Not every deletion request should blindly remove all connected business records.

Legal orientation. The EDPB guide to individual rights provides the legal orientation. Technically, you need searchable references, known storage locations and accountable staff. Identify where other retention obligations need specialist assessment.

Incidents. For a possible data incident, establish who can stop the workflow, what investigation information should be preserved and who performs the data-protection assessment. A technical operator should not be left to decide alone whether an external notification is required. Include the escalation route in the runbook.

The preparation package should contain:

• purpose and data-flow records
• suppliers and contracts
• access design
• retention and deletion procedures
• test cases
• outstanding legal decisions

Give every open question an owner and resolve it before the processing that depends on it.

Synthetic run. Run a synthetic case through the entire process and follow its copies to the intended deletion point. Test a failure, a support access and a revoked account. This demonstrates whether the documented design matches the deployed configuration.

Approval scope. Approval should identify the reviewed version and scope. New data categories, additional AI services or new recipient countries prompt reassessment. This makes privacy a documented property of the actual process rather than a label attached to the hosting offer.

These pages cover the service overview and the related decisions for data protection with n8n:

• n8n implementation and workflow operations
• Hand over n8n credentials and permissions
• Data protection across a document-processing workflow
• Review chatbot data, suppliers and deletion

For a workflow review, start with the task, systems involved and typical exceptions. Discuss it with modernagents.