An n8n security checklist CRM teams can actually use needs to start somewhere most generic automation-security advice never goes: what happens inside n8n itself once a workflow has touched a CRM record, not just who can log into the n8n UI. This checklist covers three surfaces that matter specifically because n8n sits between systems rather than inside just one: the credentials it holds, the execution logs it writes, and the hosting location that decides where that data actually lives.
Credentials: One Compromised Instance, Every Connected System
A single n8n instance commonly holds credentials for every system it touches: a HubSpot or Salesforce API key, an email provider’s OAuth token, a Slack webhook, sometimes a database connection string. That concentration is exactly what makes n8n useful, and exactly what makes a compromised instance a bigger event than a compromised single-purpose integration. Whoever gets access to the credential store does not just get n8n, they get standing access to every system n8n was trusted to talk to.
n8n’s own documentation on encryption key rotation describes a two-key model: a fixed instance encryption key, set once at deployment and never changed, which exists only to protect a separate data encryption key, and it is that data encryption key, the one actually encrypting credentials in the database, that can be rotated periodically as a hardening step. Rotation is self-hosted only, off by default, and a one-way migration with no rollback, so it needs a deliberate plan and a database backup before it is turned on, not a switch flipped casually. What this model does not give you automatically is scoping: n8n’s own credential store does not enforce least-privilege by itself, so the discipline of issuing a narrowly scoped API key or OAuth grant per workflow, rather than reusing one shared admin-level credential everywhere convenient, is a decision a team has to make deliberately rather than something the platform defaults to.
In practice this means treating credential creation as its own small design step rather than a one-time setup task. A HubSpot private app token scoped to read-only contact access for a reporting workflow should not be the same token used by a write-heavy deal-sync workflow elsewhere in the same instance, even though reusing one token is faster to set up. If the reporting workflow is ever compromised or misconfigured, a narrowly scoped token limits the damage to reads; a shared, broadly scoped token turns the same incident into a write-access problem across every workflow that happened to reuse it. Reviewing existing credentials against this standard periodically, not just at the point a new workflow is built, is what actually catches the drift that accumulates as an n8n instance grows past its first few workflows.
Execution Logs Are a Data Surface Too
This is the check most generic “secure your automation” content skips entirely. n8n’s own documentation on managing execution data confirms execution data, including the actual data payloads that passed through a workflow, is saved by default, and the documentation itself warns this can grow the database substantially if left unmanaged. If a workflow pulls a contact record from a CRM, that record’s fields are sitting in the execution log exactly as they passed through, not just a record that the workflow ran.
The practical implication is that a security review of an n8n instance has to check log content and retention, not just who can log into the n8n UI. n8n exposes this as configuration rather than a fixed behaviour, through four separate environment variables: EXECUTIONS_DATA_SAVE_ON_ERROR, EXECUTIONS_DATA_SAVE_ON_SUCCESS, EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS, and EXECUTIONS_DATA_SAVE_ON_PROGRESS for per-node data. Those four can also be set per workflow rather than only instance-wide, which is exactly the deliberate, per-workflow decision a CRM data field deserves rather than whatever the default happened to be when the workflow was first built. Pruning is a separate, instance-wide setting: enabled by default, deleting finished executions once they pass EXECUTIONS_DATA_MAX_AGE (336 hours, 14 days, by default) or EXECUTIONS_DATA_PRUNE_MAX_COUNT (10,000 by default), with the useful exception that any execution still new, running or waiting is never pruned.
Tagging or rating a specific execution for reference, which exempts it from automatic pruning, is worth doing consciously rather than by accident: an execution kept around for debugging purposes is also personal data kept around for longer than the retention policy otherwise intends, and that is worth knowing rather than discovering later.
Who can actually see an execution log matters as much as how long it survives. n8n’s own user roles control access to the editor and to execution history, but a team that gives every member of a small ops function the same broad role effectively gives every one of them read access to whatever CRM data has passed through any workflow, whether or not that specific person needed it for the task at hand. Reviewing execution-log access the same way a team would review CRM seat permissions, rather than treating n8n as internal tooling exempt from that discipline, closes a gap that is easy to overlook precisely because n8n feels like plumbing rather than a system holding customer data.
Self-Hosted vs Cloud Is a Residency Decision
Self-hosted versus cloud is usually framed as a cost and maintenance trade-off, and it is one, but for CRM data specifically it is also a data-residency and audit-control decision. Self-hosting keeps workflow execution data, which by the section above includes CRM payloads, inside an infrastructure boundary the business itself chooses and controls. n8n Cloud is a reasonable choice for a great deal of automation work, but the data residency question needs to be asked explicitly rather than assumed, since where execution data is processed and stored is a genuine variable, not a detail that disappears just because a managed service is doing the hosting.
Under UK GDPR, this matters most directly when personal data moves outside the UK or EEA as part of how a workflow’s data is processed. The ICO’s guidance on completing a transfer risk assessment (now referred to in UK legislation as a data protection test) sets out what a defensible assessment actually needs to cover once a restricted international transfer is identified, and it is worth checking whether a given n8n hosting choice even creates one before assuming it does not. Self-hosting inside a chosen UK or EU region removes the question for that specific infrastructure; it does not remove it for whatever other systems the workflow still talks to.
Where This Usually Goes Wrong
The most common mistake is treating n8n as internal plumbing rather than a system that holds a copy of whatever data passes through it. A workflow gets built quickly to solve an immediate problem, the credential it uses is whatever was already sitting in the credential store from an earlier build, and nobody revisits either decision once the workflow is running reliably. That is exactly how a single broadly scoped credential ends up shared across a dozen workflows built over a year, none of which were designed together and none of which anyone would deliberately choose to give the same access today.
The second common mistake is treating execution-data settings as a one-time default rather than a per-workflow decision. A workflow built early on, before the instance held any sensitive CRM data, often keeps its original logging settings unchanged even after it starts processing personal data, simply because nobody revisited the setting once the workflow’s purpose changed. Reviewing logging and retention settings whenever a workflow starts touching CRM data it did not originally touch is a cheap habit that closes this gap before it becomes a live compliance question.
n8n Security Checklist CRM Data: The Full List
| # | Check |
|---|---|
| 1 | Confirm credential encryption is active and, on self-hosted instances, the data encryption key has a rotation plan with a database backup first |
| 2 | Audit every credential for scope: one narrowly permissioned key per workflow, not one shared admin credential reused everywhere |
| 3 | Check the four EXECUTIONS_DATA_SAVE_* settings (on error, on success, manual runs, on progress) against what the workflow actually needs, per workflow if needed |
| 4 | Confirm pruning is enabled and EXECUTIONS_DATA_MAX_AGE / EXECUTIONS_DATA_PRUNE_MAX_COUNT match an actual data-protection decision, not the 14-day/10,000 defaults left unchanged |
| 5 | Review which executions are tagged or rated, since those are exempt from automatic pruning and need their own retention thinking |
| 6 | Establish where the n8n instance and its database actually reside, and whether that creates an international transfer to assess |
| 7 | Check that credential access inside n8n itself is scoped by user role, not open to every team member with instance access |
Related Reading
For the automation build side specifically, see n8n Consultancy. For the CRM foundation this kind of automation sits on top of, see HubSpot Consultancy. On the consent-data side of what an n8n workflow might be moving, Automating GDPR Consent Sync in CRM With n8n covers a closely related data-protection surface, and Automated Pipeline Hygiene covers the broader data-quality discipline this checklist sits alongside. For the platform-choice question itself, n8n vs Zapier for RevOps Automation covers the wider comparison this checklist’s residency section is one part of.
Go deeper: RevOps Automation Maturity Model · HubSpot Lead Routing Automation
Frequently Asked Questions
What is the actual security risk of storing CRM credentials inside n8n?
n8n encrypts credentials at rest using an instance-level encryption key, but a single compromised instance still exposes every credential it holds at once, not just n8n’s own data. The mitigation is scoping each credential narrowly per workflow rather than reusing one shared, high-privilege credential across everything, since n8n does not enforce least-privilege automatically.
Do n8n’s execution logs store the actual CRM data that passed through a workflow?
By default, yes. n8n saves execution data including the data payloads a workflow processed, and its own documentation warns this can grow the database substantially if left unmanaged. Separate settings control whether this is saved on success, on error, and on manual runs, and pruning is enabled by default, removing it once it passes an age or count threshold.
Does self-hosting n8n actually solve a data-residency problem?
It solves it for the n8n instance and its own database, since self-hosting lets you choose exactly where that infrastructure sits. It does not solve it for every other system a workflow connects to, so a full residency review still needs to check where each connected system itself stores data, not just where n8n runs.
Is n8n Cloud secure enough for regulated UK businesses?
It can be, but the data-residency question needs to be asked explicitly rather than assumed away by using a managed service. Where a cloud instance processes and stores execution data is a genuine variable worth confirming directly, particularly for any workflow handling personal data under UK GDPR.